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Abstract 

NASA’s Aviation Safety Program was created for the purpose of making a significant reduction in 
the incidents of weather related aviation accidents by improving situational awareness. The objectives of 
that program are being met in part through advances in weather sensor technology, and in part through 
advances in the communications technology that are developed for use in the National Airspace System. 

It is this latter element, i.e., the improvements in aviation communication technologies, that is the focus of 
the Weather Information Communications project. This report describes the final flight test results 
completed under the WINCOMM project at the NASA Glenn Research Center of the 1090 Extended 
Squitter (1090ES) and VDL Mode 3 (VDL-3) data link s as a medium for weather data exchange. It 
presents the use of 1090ES to meet the program objectives of sending broadcast turbulence information 
and the use of VDL-3 to send graphical weather images. This report provides the test requirements and 
test plans, which led to flight tests, as well as final results from flight testing. The reports define the 
changes made to both avionics and ground-based receivers as well as the ground infrastructure to support 
implementation of the recommended architecture, with a focus on the issues associated with these 
changes. 
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1.0 Overview 


Contained herein are the test requirements for the WINCOMM Transport En-route Scenario. 
The requirements set forth in this document comprehensively define the objectives and scope of 
the lab and flight tests for the transport en-route scenario. Based on these requirements, and 
these requirements alone, formal test plans shall subsequently be formulated and approved that 
will define the actual tests and test procedures. 

The WINCOMM Transport En-route Scenario test program shall demonstrate and evaluate 
the ability of two digital aviation data links to carry weather data products. One is the 1090 MHz 
extended squitter (1090ES) data link as defined by the RTCA MASPS and MOPS documents 
DO-242A and DO-260A, respectively. The 1090ES data link is seen as an effective means of 
exchanging turbulence alerts between transport aircraft in real time while en-route. The other is 
the VDL mode-3 (VDLM3) data link as defined by the RTCA MASPS and MOPS documents 
DO-224A change 1 and 2, and DO-271B, respectively. The VDLM3 data link is seen as an 
effective means of uplinking and downlinking weather information between the aircraft and the 
ground, namely (a) the downlinking of turbulence data messages from transport aircraft while 
en-route to ground data collection centers, (b) the downlinking of pilot-initiated requests for 
weather data products from aircraft in-flight to ground-based data servers, and (c) the uplinking 
of textual and graphical weather products from ground servers to transport aircraft while en- 
route. 

The air-to-air turbulence alerts shall be carried in the payload of the 1090 MHz extended 
squitters and shall be periodically broadcast in accordance with the 1090ES protocols and 
procedures as established by the above-mentioned RTCA documents. The air-to-air data 
transfers shall therefore occur on a best-efforts (i.e. unreliable) basis. The air-to-gnd 
transmission of the turbulence data messages and pilot-initiated weather data requests shall be 
occur as reliable data transfer using the TCP/IP network protocol in conjunction with the 
standard VDLM3 protocols and procedures. The weather data products on the other hand shall 
be uplinked to the aircraft as UDP based broadcasts, again within the framework of standard 
VDLM3 messaging protocols and procedures. 

The test program shall focus exclusively on the data handling aspects of the 1090ES and 
VDLM3 data links. It shall not focus on matters related to the generation, display, nor the utility 
of the message data. Consequently, the test program shall justifiably employ the use of 
prerecorded messages and data products to simulate the actual messages in form and function. 
Furthermore, the test program shall not focus on the in-space waveforms per se of the 1090ES 
and VDLM3, i.e. on their rf performance characteristics and lim itations. However, signal quality 
related factors including rf signal levels and link error recovery activity as well as aircraft 
altitude, attitude, and position shall be monitored (i.e. logged) during testing as supplemental test 
data so that any occurrences of poor link performance may be properly attributed to degraded 
link conditions. 

It should be noted that the equipment resources for the 1090ES and VDLM3 data links are not 
interdependent; neither are the messaging requirements for these data links. Therefore, separate 
test plans shall be generated: one for 1090ES testing and another for VDLM3 testing. Testing 
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shall be conducted to verify that turbulence and weather data products can indeed be carried 
onthese data links without causing a disruption to the flow of other traffic that could co-exist on 
the links. This would include any ADS-B traffic that is likely to be present on the 1090 MHz 
data link. Similarly, it would include any CPDLC traffic that is likely to use the VDLM3 data 
link. Thus, the primary objectives of the test program shall be to: 

1. Assess the performance characteristics of the 1090ES and VDLM3 data lin ks as pertains 
to errored messages, message reliability (i.e. lost messages), and message delivery 
latencies. 

2. Assess the ability of TCP/IP and UDP/IP messaging protocols to effectively network the 
aircraft with the ground server for the transmission of turbulence and weather data 
message types over the VDLM3 data links. 

3. Determine to the max im um extent possible within the lim itations of the physical 
resources available to the test program, what degradations in system performance might 
result from channel loading, channel congestion, and rf interference effects. 


2.0 1090ES Testing 

2.1 1090ES Flight System 

The 1090ES flight tests shall be conducted using two aircraft, each equipped as 
indicated in Figure 1. The aircraft shall be equipped to transmit and receive 1090 MHz 
squitters as specified in RTCA MASPS document DO-242A. Turbulence Test Alert 
(TTA) messages shall be periodically generated by the airborne computer and sent to 
1090ES transmitter. These outgoing TTA messages shall be inserted into the payload 
portion of the extended squitter by the transmitter and broadcast with min im al delay. The 
messages shall be squittered on a non-addressed basis in accordance with the ADS-B 
protocol procedures as proscribed in the above referenced RTCA documents. Incoming 
TTA messages shall be extracted from the receive squitters and forwarded to the on- 
board computer via an ethernet LAN interface. 

Receive signal quality parameters generated by the 1090 MHz receiver shall be 
forwarded to the airborne computer via the ethernet interface. These parameters shall 
include the receive signal level and error status. 

The airborne computer shall serve both as a data generator and as the flight data 
logger. It shall perform the following functions: 

(a) Periodically generate the outgoing TTA messages as per Section 2.2, and 
send them to the 1090ES transmitter, 

- continued - 
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(b) Log and display the incoming and outgoing TTA messages, 

(c) Log and display the signal quality parameters output from the 1090ES 
receiver, and 

(d) Log and display the flight sensor data. 

The data logs shall be time stamped and recorded as specified in Section 2.3. 
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Figure 1. Commercial Transport 1090 ES Airborne System 


2.2 Turbulence Test Alert (TTA) message 

The turbulence test alert (TTA) messages shall be 16 bits in length. The TTA 
message shall consist of one 16-bit integer which shall represent the message number. 
The message number shall be sequentially incremented with each transmission. 

The outgoing TTA messages shall be generated and passed to the 1090 MHz 
transmitter at a nominal rate of once-per-minute. The rate shall be “front panel” 
adjustable to allow the flight operator to set the message interval within the range of 
5 to 60 seconds. 

The outgoing TTA messages shall be transferred from the airborne computer to the 
transmitter via an ARINC 429 interface. The successful transmission of the outgoing 
TTA messages shall be echoed back to the airborne computer. TTA messages issued by 
the airborne computer not receiving a con fir mation echo within 5 seconds shall be 
immediately re-issued with the same message sequence number. 
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2.3 1090ES Event Logs 


The on-board computer shall maintain an event log of the data messages, the link 
parameters, and the flight parameters throughout the test flights. All events shall be time 
and date stamped. The events shall include the following: 

(a) Incoming and outgoing TTA messages, 

(b) Receive signal quality, 

(c) Errored and discarded messages, and 

(d) Aircraft position, altitude, and heading 

The file format of the event log is TBD. 


2.4 1090ES Ground Segment 

The 1090ES testing shall be conducted exclusively via the air-to-air data links. No 
ground based equipment shall be required. 

2.5 1090ES Test Flight Profiles 

The test flights shall be conducted under straight and level conditions. The two 
aircraft shall fly essentially parallel flight paths at approximately the same altitude. The 
operational separation of the two aircraft during testing shall not exceed 75 nmi. 


3.0 VDLM3 Testing 

VDLM3 testing shall be conducted using the NASA Glenn LearJet 25 research aircraft in 
conjunction with the FAA ground station located at FAA Technical Center in Atlantic City, New 
Jersey. The system shall be configured to use one data channel of a 2V2D configuration. 
Indicated in Figure 2 are the airborne and ground segments of the VDFM3 test system. 

3.1 VDLM3 Flight Segment 

The VDFM3 radio shall operate in full compliance with the protocols and procedures 
for VDFM3 communications as defined in RTCA MASPS and MOPS documents DO- 
224A change 1 and 2, and DO-27 IB, respectively. The flow of messages in and out of 
the radio shall be managed by the Communications Management Unit (CMU). Incoming 
textual and graphical data products shall be displayed on the IDC 900. The IDC 900 
shall also serve as the operator interface for the retrieval of the weather data products and 
for the issuance of weather data product requests. Supplemental I/O to and from the 
CMU shall include an ARINC 429 interface to input GPS time and position information, 
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and a RS-232 port to interface the link protocol parameters to the airborne computer. 
Link performance parameters from the radio shall be sent to the airborne computer, also 
through an RS-232 interface. 



Figure 2. Commercial Transport VDLM3 Airborne and Ground Systems 


The airborne computer shall serve as both a Turbulence Test Message (TTM) 
generator and as a flight event/data logger. The TTM shall be generated as specified in 
Section 3.3.1 and transferred to the CMU via an ARINC 429 interface using the 
Williamsburg vl protocol. The individual TTMs shall be logged in the airborne 
computer along with the flight data from the flight sensors and the signal quality 
parameters from the radio. The content and format of the flight event/data log shall be as 
specified in Section 3.4. 

The CMU shall be assigned the IP address 192.168.1.2. 


3.2 VDLM3 Ground Segment 

The VDLM3 ground segment shall consist of the FAA ground station together with a 
NASA supplied WINCOMM Gnd Server as indicated in Figure 2. The FAA shall 
provide an ethernet interface to its Ground Network Interface (GNI) subsystem. The 
interface shall conform to the FAA-NASA ICD, reference document 5.1. The individual 
Weather Test Product (WTP) APDUs as defined in RTCA DO-267 shall exist as static 
files within the WINCOMM Gnd Server. NASA shall provide the client/server software 
that will reside in the WINCOMM Gnd Server. An NTP connection shall provide an 
accurate and stable time base. 
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The WINCOMM Gnd Server shall constitute the server portion of a TCP/IP 
client/server network architecture. It shall perform the following functions: 

(a) Log and display the TTM transmitted to the ground from the aircraft, 

(b) Maintain the WTP APDU files for uplinking to the aircraft, 

(c) Issue on a periodic basis WTP files for broadcast from the standard set of 
textual and graphical weather data products as indicated in Section 3.3.3, 

(d) Issue operator-requested WTP files for broadcast from the request set of 
graphical weather data products as indicated in Section 3.3.3, 

(e) Log and display the issuance of all (both standard and request) WTP files, 
and 

(f) Log and display the Weather Request Messages. 

The WINCOMM Gnd Server shall be assigned the IP address 192. 168. 1. 1. 


3.3 VDLM3 Messages 

3.3.1 Air-to-Gnd Turbulence Test Message (TTM) 

The Turbulence Test Message (TTM) shall be generated by the airborne computer. It 
shall be transferred to the CMU via an ARINC 429 interface using the Williamsburg vl 
protocol. The TTM shall be transmitted to the ground in accordance with the VDLM3 
protocols procedures as specified in RTCA MASPS document DO-224A. 

The TTM shall be 77 bytes in length. The TTM shall contain the following comma- 
delimited fields: 


Bvte No. 

Length 

Contents 

Description 

1 - 12 

12 

$TURBULENCE, 

Start of message 

12-25 

13 

hh:mm:ss.sss, 

Timestamp 

26-31 

6 

nnnnn, 

Sequence no. 

32-75 

44 

ASCII text string 

Free text messagt 

76-77 

2 

ASCII c/r and 1/f 

End of message 


Notes: 

1. The timestamp shall be the UTC time of generation of the message; the 
resolution shall be one millisecond. 


2. The sequence number shall start at 00001 and increment by one with each 
message sent. It shall roll over from 99999 back to 00001. 
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3. The 44-byte free text message shall be generated by the operator in real time 
via the airborne computer. Unused characters shall default to the underscore 
character (ASCII 0x5F). 


4. Example messages: 

Byte 1 2 3 4 5 6 7 

12345678901234567890123456789012345678901234567890123456789012345678901234567 

$ TURBULENCE, 09:19:51 .000,00123, ° r 1 

$TURBULENCE, 09 : 20 : 51 . 000, 00124, This is a free text message. ° r 1 


The TTM shall be generated and transmitted at a nominal rate of once per minute. 

The rate shall be “front panel” adjustable to allow the flight operator to set the message 
interval within the range of 5 to 60 seconds. 

The CMU shall forward the TTM as a TCP/IP v4 client to the ground server. The 
TCP Destination port for the TTM messages shall be 1 1502. The TCP connections once 
established shall be maintained. 


3.3.2 Air-to-Gnd Weather Data Requests 

Weather product 'Request messages shall be transmitted from in-flight test aircraft to 
the ground in accordance with the VDLM3 protocol procedures as specified in RTCA 
MASPS document DO-224A. The Request messages shall be manually initiated on- 
board the test aircraft via a key press (or series of key presses) on the IDC. The 
selectable weather test products (WTPs) shall be those listed in the Request Set of 
Appendix A. 

The content and format of the Request message shall be as specified in Section 6.2.2 
of Reference Document 5.2. 

The CMU shall issue the Request messages as a TCP/IP v4 client to the ground server. 
The TCP Destination port for the Request messages shall be 1 1503. The TCP 
connections once established shall be maintained for 2 minutes in the absence of message 
traffic on the connection. 


3.3.3 Gnd-to-Air Weather Test Products (WTP) 

The ground station shall be capable of transmitting a variety of weather textual and 
graphical test products (WTP) as specified in Appendix B. Two categories of WTPs are 
indicated: a standard set and a request set. WTP from the standard set shall be issued 
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with a higher priority of transmission than those from the request set. All WTP files shall 
be compressed using the Deflate file compression algorithm. 

The entire set of standard WTP shall be broadcast at 5-minute intervals throughout the 
test flights. WTP from the request set shall be transmitted once per request on an as- 
time-available basis. The WINCOMM Gnd Server shall issue the WTP files to the GNI 
of the ground station on a time scale consistent with the rate at which they are capable of 
being transmitted over the VDLM3 uplink. A channel utilization margin of nominally 
25% shall be allocated to allow for the transmission of other digital data messages that 
may be assigned to the same data link (e.g. CPDLC messages). The WINCOMM Gnd 
Server shall queue the requested WTP for transfer to the GNI so as to preserve that 
unused channel margin. 

The WINCOMM Gnd Server shall transfer the WTP files to the GNI as UDP IP 
datagrams. The files shall be broadcast using IP address 192.168.1.2, port number 
1 1501. The IP parameters and fields shall be set as follows: 

(a) IP version: 4 

(b) Type of service, precedence bits: 2 for high priority standard WTPs 

1 for low priority request WTPs 

(c) Time-to-live: 1 

(d) Protocol: 17 (UDP) 

(e) IP data payload: WTP file in Deflate compressed form. 

Large WTPs shall be segmented at the IP layer. The datagram MTU shall be 922 
bytes. Each segment shall include a 1-byte IPI (OxCC = IPv4). 


3.4 VDLM3 Flight Logs 

The airborne computer shall maintain an event log of the data messages link 
parameters, and flight parameters throughout the test flights. The events shall include the 
following: 

(a) All TTMs 

(b) All Request messages 

(c) Ah WTPs 

(d) Receive signal level as issued by the radio 

(e) Aircraft position, altitude, and heading 

All events shall be date and time stamped. In addition, a supplemental written flight 
log shall be maintained by the test operator. The written log shall document pertinent 
comments and observations of the operator as deemed appropriate. 
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3.5 VDLM3 Ground Server Logs 


The WINCOMM Gnd Server shall maintain an event log of all message traffic it 
issues and all messages it receives. The events shall include the following: 

(a) All TTMs 

(b) All Request messages 

(c) The file name of all WTPs transmitted 

(d) The connect and disconnect times for all TCP sessions 

All events shall be date and time stamped. In addition, a supplemental written log shall 
be maintained by the ground test operator. The written log shall document pertinent 
comments and observations of the operator as deemed appropriate. 


3.6 VDLM3 Test Flight Profdes 

The test flights shall be conducted under straight and level conditions at altitudes in 
the range of 5,000 to 40,000 MSL. The test aircraft shall fly both radial and crossing (i.e. 
fly-by) patterns within the known operational range of the FAA ground station. 


4.0 Lab Testing 

Lab tests shall be conducted in advance of the flight tests. The testing shall be conducted for 
the purpose of: 

(a) Verifying the functionality of the 1090 and VDLM3 flight equipment, 

(b) Verifying the interoperability of the air-to-air (1090ES) systems, 

(c) Verifying the TTA message formats, 

(d) Verifying the functionality WINCOMM Gnd Server software, 

(e) Verifying the interoperability of the WINCOMM Gnd Server with the GNI, 

(f) Verifying the interoperability of the VDLM3 airborne and ground segments, 

(g) Verifying the TTM message formats and the TCP message exchange processes, 

(h) Verifying the WTP datagram formatting, segmentation, and re-assembly, 

(i) Verifying the airborne and ground data log structure and operation, and 
(]) Establishing operational proficiency with the flight and ground systems. 

The lab tests shall be accomplished in a non-radiating mode; i.e. all rf interconnections shall 
be made using coaxial cables and appropriately sized attenuators. 
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5.0 Reference Documents 


5.1 VDL Mode 3 Ground Network Interface (GNI) IP Gateway Interface Control 
Document, FAA-NASA-ICD-01, version 0.5, September 1, 2004. 

5.2 Software Requirements Specification (SRS) for the CMU-900 Weather Aircraft 
Operational Communications Application (AOC) 

Rockwell Collins document CPN xxx-xxxx-001 issued August 12, 2004. 


Transport En-Route Scenario 


Test Requirements 


Page 13 of 15 



APPENDIX A 


Weather Data Products (WDPs) 


Standard Set 

Product 

Textual Identifier 

Aviation Routine Weather Reports (METARs) 0 

Combined with Special Aviation Reports (SPECIs) 

Terminal Area Forcasts (TAFs) and their amendments 1 

Significant Meteorological Information (SIGMETs) 2 

Convective SIGMETs 3 

Airman’s Meteorological Information (AIRMETs) 4 

Pilot Reports, both urgent and routine (PIREPs) 5 

Severe Weather Forecast Alerts (AWWs) 6 

Graphical 

NEXRAD national, 10 k il ometer resolution 401 

Region: 0M, Product: 01 

Cloud Tops / Echo Tops 401 

Region: 0M, Product: 02 


- continued - 
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Weather Data Products (WDPs) — Continued 


Request Set 
Textual 


Product 

Identifier 


( none ) 


Graphical 

NEXRAD regional, 10 kilometer resolution 401 

Regions: 0V, 0W, 0Z, Product: 01 

Icing 401 

Region: 0M, Product: 06 
Flight Levels: 24, 30, 34 
Forecast Time: 00 

Turbulence 401 

Region: 0M, Product: 05 
Flight Levels: 24, 30, 34 
Forecast Time: 00 

Wind / Temp Aloft 401 

Region: 0M, Product: 04 
Flight Levels: 24, 30, 34 
Forecast Time: 00 


Transport En-Route Scenario 


Test Requirements 


Page 15 of 15 




WINCOMM 


TRANSPORT EN-ROUTE SCENARIO 


VDL MODE 3 
TEST PLAN 


Prepared by: 


Approved by: 




Russ Jirbwg - L$ie Logic Systems 

D^te 


3/3 )M 

Barnes Griner - NXSA GRC 

Date 

Scenario Lead 




Michael Jarrell - NASA GRC 
WINCOMM Level III Project Mgr. 

Date 


Transport En-Route Scenario 


VDLM3 Test Plan 


Page 1 of 16 



REVISION HISTORY 


DOCUMENT: 

WINCOMM Transport En-Route Scenario 
VDL Mode 3 Test Plan 

FILE NAME: 

TransportTestPlan_VDLM3_vl .doc 

REV 

DATE 

DESCRIPTION OF CHANGE 

0.0 

11/09/04 

Draft 

1.0 

3/31/05 

Initial release. 


Transport En-Route Scenario 


VDLM3 Test Plan 


Page 2 of 16 



TABLE OF CONTENTS 


Page 

1.0 Overview 4 

1.1 Test Requirements 4 

1.2 Test Objectives and Approach 4 

1.3 Participants 5 

2.0 Laboratory Tests 5 

2. 1 WINCOMM Airborne Computer (WAC) Subsystem Tests 6 

2.2 WINCOMM Ground Server Subsystem Tests 7 

3.0 System Integration and Ground Testing 8 

3.1 Airborne Subsystem Testing 9 

3.2 WINCOMM Ground Server Testing 10 

4.0 Aircraft Installation and Checkout 11 

5.0 Ramp Testing 11 

6.0 Preflight Testing 12 

7.0 Flight Testing 12 

7.1 Test Flight #1 13 

7.2 Test Flight #2 13 

7.3 Test Flight #3 14 

7.4 Test Flight #4 14 

7.5 Test Flight #5 15 

8.0 Reference Documents 15 

9.0 ADPU Test Products 16 


Figure 1. Commercial Transport VDLM3 

Airborne and Ground Systems 5 


Transport En-Route Scenario 


VDLM3 Test Plan 


Page 3 of 16 



1.0 Overview 


Contained herein is the test plan for the validation and demonstration of the VDL mode 3 
(VDLM3) digital data link as a means of providing weather data and turbulence data to and from 
transport aircraft in real time while en-route. 


1.1 Test Requirements 

The requirements for the WINCOMM VDLM3 data link test program are contained 
within the WINCOMM Transport En-Route Scenario Test Requirements document 
(Reference document 8.1). 


1.2 Test Objectives and Approach 

The purpose of the VDLM3 test program is to establish the effectiveness of VDLM3 
digital data links as a communications technology for sending turbulence data from in- 
flight transport aircraft to weather data collection centers on the ground, and for uplinking 
weather data, both textual and graphical, from the ground to in-flight transport aircraft. It 
is not the purpose of the test program to evaluate the effectiveness of the data transmitted 
over the VDLM3 lin ks from an operational standpoint, nor is it the purpose of the test 
program to address the man-machine related considerations of the data of the air or 
ground data displays. The testing thus shall be conducted using canned data products that 
simulate in form and function the actual turbulence and weather data products that might 
eventually be carried operationally on these links. 

The flight test program shall be conducted by NASA in conjunction with its Project 
partners. One research aircraft shall be outfitted as indicated in Figure 1. The airborne 
avionics and displays shall be commercially available units. Software modifications shall 
be made to these units as necessary to provide the capabilities specified in the test 
requirements (Reference document 8.1). The test flights shall be conducted in 
cooperation with the FAA using the VDFM3 ground station located at the FAA 
Technical Center in Atlantic City, New lersey. NASA shall provide the ground server 
computer and software, which will interface to the GNI subsystem of the VDFM3 ground 
station. The flight tests shall follow flight profiles that will serve to demonstrate and 
evaluate the communications aspects of the VDFM3 technology as prescribed herein. 

The testing shall be completed in phases. The first phase shall consist of the 
laboratory functional tests associated with the development or modification of the 
individual airborne and ground subsystems. These tests shall be conducted separately by 
each project partner at their own facilities. The second phase shall consist of the system 
level functional test associated with the integration of the flight system and ground 
system, and the verification testing of their interoperability. These tests shall be 
conducted jointly at the FAA Technical Center. The testing shall involve the FAA’s 
VDFM3 ground station to provide a VHF link between the airborne and ground 
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segments. The RF interconnect shall be cabled (i.e. non-radiating). The third phase shall 
consist of the flight tests using the NASA aircraft in conjunction with the FAA’s ground 
station. Formal test procedures and checklists shall be generated and followed for both 
the airborne and ground segments when conducting the flight tests. 



Figure 1. Commercial Transport VDLM3 Airborne and Ground Systems 


1.3 Participants 

NASA shall be responsible for the overall project management, for the prehminary 
integration and testing of the airborne hardware and software, for the ground server, for 
the test flights, and for the subsequent data analysis and reporting. Rockwell Collins 
shall be responsible for the software design modifications that are required to the CMU 
and display unit. Rockwell Collins shall also participate in the overall system design, and 
shall provide technical support during the system integration and ground testing as well 
as the follow-on flight tests. The FAA shall be responsible for the design and 
implementation of the Ground Network Interface (GNI). In addition, the FAA shall 
participate in the overall system design, and shall provide operational support during the 
system integration and ground testing activities as well as the follow-on flight tests. 


2.0 Laboratory Tests 

Laboratory testing of the airborne and ground subsystems shall be performed prior to the 
integration and testing at the system level. Functional verification testing of the avionics and 
display units shall be conducted by Rockwell Collins prior to the delivery of those units to 
NASA. Similarly, the FAA shall verify the compatibility and message handling capability of the 
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ground server interface. NASA shall develop and test the software that will reside in the 
airborne and ground server computers. NASA shall also provide the computer for the ground 
server as well as the computer, equipment racks, ancillary equipment, cabling, and installation of 
the airborne segment. The laboratory testing shall specifically include the following subsystem- 
level tests. 


2.1 WINCOMM Airborne Computer (WAC) Subsystem Tests. The test operator shall 
follow the procedures outlined in the VDLM3 Operations document (Reference 
document 8.3) in setting up the VDLM3 airborne system as well as the VDLM3 ground 
system. The operator interface screen of the WAC program provides the operator with 
the necessary visibility into the operational status of the Williamsburg data transfers from 
the WAC to the CMU. The interface screen also provides the means for the operator to 
synchronize the system (i.e. WAC) clock to a GPS time signal, to adjust the message 
timing, and to observe the message history. The test operator shall perform functional 
tests to verify the format, content, and timing, as appropriate, of the following data 
messages: 

2.1.1 Turbulence Test Message (TTM). This test shall be performed using the WAC 
Lab VIEW program, which manages the ARINC 429 based data communications 
between the WAC computer and the CMU. These data transfers are implemented 
in accordance with the Williamsburg (version 1) bit-oriented file transfer 
protocol as defined in Reference document 8.2. The program simulates the 
transference of TTM message files. Each TTM contains a 77-byte data field as 
defined in the WINCOMM Transport En-Route Scenario Test Requirements 
document (Reference document 8.1), and a 5-byte ARINC 619 accountability 
header. The test operator shall verify the following operational capabilities: 

2.1. 1.1 WAC to CMU data communications. By observing the progression of 
status and error messages provided on the interface screen, the test operator 
shall verify that WAC program successfully establishes communications 
with the CMU for the Williamsburg 429 based data transfers. The operator 
shall also verify that the re-linking process, which re-establishes the 
Williamsburg protocol communications, is functional. 

2.1. 1.2 TTM file transfer. The operator shall verify that WAC program 
successfully generates TTM’s on an interval- adjustable basis. Additionally 
the operator shall verify (1) that free text messages can be inserted into the 
TTM’s, (2) that individual messages can be sent on an immediate basis, and 
(3) that the timed messaging can be inhibited while at the same time 
allowing individual messages to be transmitted on an immediate basis. 

2.1. 1.3 TTM message history. The test operator shall verify that the TTM’s sent 
to the CMU register in order on the interface screen. 
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2.1. 1.4 GPS time synchronization. With the KLN94 GPS receiver active, the 
operator shall verify that the system clock can be synchronized to the GPS 
to within 1 second. 

2.1. 1.5 Log file. The test operator shall verify that the WAC program is consistently 
logging the TTM’s issued to the CMU with the correct time stamp, message 
format, and message content. 


2.1.2 VDLM3 radio trace port messages. This test shall be performed using the 
Rockwell Collins terminal emulator, debugmon.exe. The test operator shall verify 
that the parameters from the VDLM3 radio are being received and displayed on 
the computer monitor, and that the data log is being properly generated. 

2.1.3 CMU maintenance port messages. This test shall be performed using a terminal 
emulator application such as TeraTerm. The test operator shall verify that the 
parameters from the CMU maintenance port are being received and displayed on 
the WAC monitor, and that the data log is being properly generated. 

2.1.4 ICAO address. The test operator shall verify (1) that the appropriate GPS data is 
being received and displayed on display unit (IDC 900), (2) that the XPDR1 status 
under the Peripheral Status menu changes from ABSENT to PRESENT , and (3) 
that the ICAO address sent to the CMU appears under the ACARS menu on the 
display unit (IDC 900). 

2.1.5 GPS and flight parameter data. With the KLN94 GPS active, the test operator 
shall verify that the latitude, longitude, ground speed, and altitude data is being 
received and displayed on the display unit (IDC 900), and that the GPS status 
under the Peripheral Status menu changes from ABSENT to PRESENT. 


2.2 WINCOMM Ground Server Subsystem Tests. Functional testing shall be performed 
to verify the format, content, and timing, as appropriate, of each function the server 
performs. These tests shall be performed using test client programs that simulate the 
actual messages that the server will receive. 

In preparation for this testing, the test operator shall con fir m that the registry edit, MTU 
change, and clock synchronization setting described on the About tab have been 
performed. Secondly, the test operator shall con fir m that the system variables, IP 
addresses, and port numbers that appear on the System Parameters tab are set to their 
predetermined values. Upon starting the server program, the test operator shall verify 
that the GNI Port LED and GNI Ready LEDs are lit, and that the Enable/Inhibit switch 
on the Outgoing Messages tab is in the Enable position. 

The specific tests shall be as follows: 
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2.2.1 Turbulence Test Message (TTM). This test shall be performed using a test 
client that generates simulated TTM messages. The test operator shall verify that 
the simulated TTM messages appear sequentially on the Turbulence Messages tab 
with the correct content and format. The test operator shall also verify that client 
will automatically connect to the server. 

2.2.2 WTP request message. This test shall be performed using a test utility that 
generates simulated WTP request messages. The test operator shall verify that 
the simulated WTP request messages appear sequentially on the Product Requests 
tab with the correct content and format. The test operator shall verify that the 
server will disconnect from the client after the set idle time, and that the client 
will automatically reconnect with the resumption of message traffic. 

2.2.3 WTP ADPUs, both standard and request. This test shall be performed using a 
representative set of ADPUs that simulate actual WTPs. The test operator shall 
verify that the file names of the simulated WTPs appear sequentially on the 
Outgoing Messages tab with the proper timestamps. In the process, the test 
operator shall verify that the WTPs are issued in accordance with the intended 
timing and sequencing. The test operator shall also verify that the WTP request 
queue functions properly, and that the issuance of the outgoing WTPs responds 
properly to the Enable/Inhibit switch on the Outgoing Messages tab. Finally, the 
test operator shall verify that the ADPU files are properly fragmented and 
encapsulated into IP datagrams using the Ethereal network protocol analyzer. 

2.2.4 IP message prioritization. The test operator shall verify that the TOS bits in the 
IP headers of the standard and request WTPs are properly set by direct 
examination of the IP header using the Ethereal network protocol analyzer. 

2.2.5 GNI flow control. This test shall be performed using a test utility program that 
simulates the GNI flow control messages. The test operator shall verify that the 
flow of outgoing messages ceases when the inhibit command is received, and that 
the flow resumes when the resume command is received. 

2.2.6 Log files. The test operator shall stop the server program and examine each of the 
log files to verify their content and format. The test operator shall also verify that, 
when restarted, the program appends new data to the end of the existing log files, 
and that when the log files are deleted (or moved), the program creates new files 
in their place. 


3.0 System Integration and Ground Testing 

Upon completion of the laboratory testing (Section 2.0), the airborne system components 
shall be integrated in preparation for system-level testing at the FAA Technical Center in 
Atlantic City, New Jersey. Concurrently, the ground server shall be integrated into the FAA’s 
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VDLM3 ground station. The ground station shall provide the VDLM3 link between the airborne 
segment and the ground server. During the initial ground test (i.e. Ground Test #1), the RF 
interconnect between the airborne radio and the ground station shall be cabled (i.e. non- 
radiating). A second ground test (Ground Test #2) shall be conducted wherein the RF link 
between the airborne and ground segments shall be active (i.e. radiating on-air). 

The purpose of the ground testing is to verify that the airborne and ground segments are 
mutually interoperable and fully functional. The following specific system-level tests shall be 
performed in conjunction with the VDLM3 ground station. The test operator(s) shall follow the 
procedures outlined in the VDLM3 Operations document (Reference document 8.3). 

3.1 Airborne Subsystem Testing. Tests shall be performed to verify the subsystem 

interconnects (i.e. cabling and pin-outs) are compatible and functional. The specific tests 

shall include the following: 

3.1.1 Subsystems interconnects, power supply voltages, and tuning panel. The test 
operator shall verify that (1) the subsystem interconnects (i.e. cabling and pin- 
outs) are properly configured, (2) the power supply voltages are properly set, (3) 
the tuning panel is functional, and (4) all RF cables are properly connected/ 
terminated. 

3.1.2 TTM TCP connection. The test operator shall verify that the CMU can 
establish a TCP connection with the TTM port on the ground server. 

3.1.3 TTM transmission. The test operator shall verify that the WAC is generating 
TTM’s and transferring those messages to the CMU, and that the CMU in turn 
transmits those messages to the ground station. 

3.1.4 WTP Request TCP connection. The test operator shall verify that the CMU can 
establish a TCP connection with the WTP request port on the ground server. 

3.1.5 Uplinked WTP reception and display. The test operator shall verify that the 
standard and request WTP sent from the ground server via the ground station are 
received and properly displayed on the display unit (IDC 900). 

3.1.6 Airborne event / message log. The test operator shall verify that the uplinked 
WTP headers are logged on the WAC along with the correct time stamp. 

3.1.7 VDLM3 Voice Channel Communications. The test operator shall con fir m that 
the voice channel of the VDLM3 2V2D configuration is functional. Tests shall be 
conducted using push-to-talk microphones. 

3.1.8 VDLM3 Radio Trace Port Message. This test shall be performed using the 
Rockwell Collins terminal emulator, debugmon.exe. The test operator shall verify 
that the parameters from the communications port of the VDLM3 radio are being 
received and displayed on the WAC monitor. 
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3.1.9 CMU Maintenance Port Message. This test shall be performed using a terminal 
emulator application such as TeraTerm. The test operator shall verify that the 
parameters from the CMU maintenance port are being received and displayed on 
the WAC monitor. 

3.1.10 ICAO Address. This test shall be performed as described in Section 2.1.4. 

3.1.11 GPS data. This test shall be performed as described in Section 2.1.5. 


3.2 WINCOMM Ground Server Testing. Functional testing shall be performed to verify 
that the server - GNI interconnect is operational, and that message formats, content, and 
timing, as appropriate, are correct. 

In preparation for this testing, the test operator shall con fir m that the registry edit, MTU 
change, and clock synchronization setting described on the About tab have been 
performed. Secondly, the test operator shall con fir m that the system variables, IP 
addresses, and port numbers that appear on the System Parameters tab are set to their 
predetermined values. Upon starting the server program, the test operator shall verify 
that the GNI Port LED and GNI Ready LEDs are lit, and that the Enable/Inhibit switch 
on the Outgoing Messages tab is in the Enable position. 

The specific functional tests that are to be performed are as follows: 

3.2.1 TTM TCP connection. The test operator shall verify that the airborne computer 
can automatically connect to the server, and will automatically reconnect 
following restoration of the link following a simulated loss of signal. 

3.2.2 WTP request message TCP connection. The test operator shall verify that the 
CMU can automatically connect to the server, and will automatically reconnect 
following restoration of the link following a simulated loss of signal. 

Additionally, the test operator shall verify that server will automatically cause a 
disconnect after the prescribed idle period. 

3.2.3 Reception of Turbulence Test Messages (TTM). This test requires the airborne 
segment to establish a TCP connection with the server, and to send a series of 
TTMs. The test operator shall verify that Turb Port LED is lit, and that TTM 
messages are appearing on the Turbulence Messages tab. In addition, the test 
operator shall verify that the TTMs have the correct content and format, and are 
properly time stamped. 

3.2.4 Reception of WTP request messages. This test requires the airborne segment to 
establish a TCP connection with the server, and to send a series of WTP request 
messages. The test operator shall verify that REQ Port LED is lit, and that WTP 
request messages are appearing on the Product Requests tab. In addition, the test 
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operator shall verify that the messages have the correct content and format, and 
are properly time stamped. 

3.2.5 Issuance of standard and request WTP uplink ADPUs. The test operator shall 
verify that ADPU files are issued to the GNI as indicated on the Outgoing 
Messages tab. Concurrently, reception of the WTPs by the airborne segment shall 
be con fir med. As the WTPs are issued, the test operator shall con fir m that the 
flow of WTPs is interrupted in accordance with the GNI flow control status. 

3.2.6 Verification of UDP message priorities. The test operator shall verify that the 
IP headers for the standard and request WTP ADPUs contain the correct TOS 
bits. This test shall be accomplished with the aid of the Ethereal network 
protocol analyzer. 

3.2.7 Verification of UDP fragmentation. The test operator shall verify that the 
max im um size of the uplink UDP datagrams sent to the GNI does not exceed the 
prescribed value as specified on the About tab. This test shall be accomplished 
with the aid of the Ethereal network protocol analyzer. 

3.2.8 Verification of the fog fifes. The test operator shall stop the server program and 
examine each of the log files to verify their content and format. 


4.0 Aircraft Installation and Checkout 

Upon completion of the ground tests (Section 3.0), the airborne system shall be installed on 
the NASA LearJet 25. During this installation at the Glenn Research Center, the functionality of 
the system shall be verified by connecting the airborne equipment to the FAA-provided ground 
station. This testing shall be accomplished using cabled (i.e. non-radiating) interconnects. The 
purpose of these tests shall be to verify prior to the start of flight testing that the airborne system 
is fully functional as it is installed in the aircraft. 


5.0 Ramp Testing 

Upon completion of the installation and checkout of the airborne system in the aircraft 
(Section 4.0), the aircraft shall be relocated to the Atlantic City airport. The ground server shall 
be relocated to the FAA Technical Center and re-integrated with the FAA’s VDLM3 ground 
station. The functionality of the system shall be re-established using an active (i.e. on-air) 
VDLM3 channel between the airborne and ground segments. During ramp testing, the airborne 
equipment shall be powered from ground power. The purpose of these tests shall be to verify 
that the system, including the radio and antenna, is fully functional in preparation for the start of 
flight testing. 
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The ramp tests shall be a subset of the flight test. They shall provide verification of the 
following test instrumentation, voice communications links, and GPS operation: 

(1) VDLM3 data link (aircraft - ground station Tx/Rx VDLM3 radio links), 

(2) TTM message generation, text messaging, and logging, 

(3) Request WTP message generation and logging, 

(4) Reception, display, and logging of uplinked WTPs, 

(5) VDLM3 voice channel communications, 

(6) Iridium satellite voice communications (as a backup voice channel), and 

(7) GPS time and location message generation. 


6.0 Preflight Testing 

Preflight tests shall be conducted prior to each test flight. These tests shall be conducted with 
the aircraft on the ramp with the engines running. The airborne equipment shall be powered-on 
using ship-board power. System-level tests shall be executed prior to take-off to verify the 
following functions: 

(1) Functionality of the VDLM3 avionics, ancillary equipment, and computer software, 

(2) Operation of the VDLM3 voice channel communications, 

(3) Operation of the VHF AM voice channel as a communications backup, and 

(4) Operation of the GPS. 

All systems must be fully functional as a condition for take-off. 


7.0 Flight Testing 

The test flights shall be conducted in coordination with the FAA Technical Center in Atlantic 
City, NJ. The test flights shall be flown within the coverage area of the ground station located at 
the FAA Technical Center. The test flights shall be conducted in accordance with the following 
procedures and objectives. 

Two test flights shall be made per day: a morning flight and an afternoon flight. Preflight 
system tests shall be conducted prior to each Test Flight as indicated in Section 6.0 to verify that 
all systems are operating and fully functional. Voice coordination with the WGS operator(s) 
shall be established prior to takeoff using the VDLM3 voice channel and the VHF AM radio. 

The WGS shall be configured to broadcast a full set of standard test products consisting of 7 
WTPs, and a full set of request test products consisting of 14 WTPs as listed in Section 9.0. 

During each of the test flights, the airborne and ground test operators shall maintain a written 
log of the significant events and times to aid in the correlation of the flight data logs with those 
recorded at the WGS. 
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7.1 Test Flight #1. Test Flight #1 shah serve as a “dress rehearsal” to the fohow-on 
operational data gathering test flights. The primary objectives of Test Fhght #1 are: 

(1) to verify the operation of the VDLM3 data communications equipment and software, 

(2) to verify the operation of the radio voice communications, and 

(3) to evaluate the general fhght procedures. 

The fhght parameters for Test Fhght #1 shah be as follows: 

7.1.1 Flight pattern. Radial from Atlantic City airport, straight and level at 35,000 feet 
(nominal), out to the lim it of coverage, and return. The airborne operator shah 
mark the lim it of coverage as the point at which the CMU VDL3 Link Status 
indicates “No Net,” indicating a loss of network connectivity. The aircraft shah 
continue on its out-bound course beyond that point for 3 minutes, in order to test 
protocol timer expiration, before turn back toward Atlantic City. Fhght duration is 
approximately 1 hour. 

7.1.2 Data Communications. TTM’s shah be transmitted regularly to the WGS at 60- 
second intervals. The WGS shah repeatedly broadcast one (and only one) of the 
standard WTPs regularly at 10-second intervals. During the test fhght the airborne 
operator shah issue requests for one of two request WTPs an on alternating basis, 
at 5-minute intervals. Upon receiving the request, the WGS shah broadcast the 
requested WTP. 

7.1.3 Post Flight Activities. Upon completion of the test fhght, the aircraft and ground 
logs shah be examined to verify the individual data formats, content, and time 
stamps, and to verify that the aircraft and ground logs can be correlated. A formal 
debriefing of the fhght shah be held with the airborne test operators, ground test 
operators, and the phots for the purpose of reviewing the test procedures, the 
preliminary test results, and to revise as necessary the fohow-on fhght plans. 


7.2 Test Flight #2. Test Fhght #2 shah be the first of four operational data gathering flights. 

The fhght parameters for this test fhght shah be as fohows: 

7.2.1 Flight pattern. Two legs, each leg along a radial from the Atlantic City airport 
out to the lim it of coverage and return, straight and level at 35,000 feet (nominal). 
Fhght duration is approximately 2 hours. 

7.2.2 Data Communications. TTM’s shah be transmitted regularly to the WGS at 60- 
second intervals. The WGS shah cychcahy broadcast the full set of standard 
WTPs at 10-second intervals throughout the duration of the test fhght. During the 
second leg only of the test fhght, the airborne test operator shah issue requests for 
request WTPs at 5-minute intervals. The WGS shah broadcast the requested WTPs 
interspersed in among the standard WTPs. 
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7.2.3 Post Flight Activities. Upon completion of the test flight, the aircraft and ground 
logs shall be examined to verify the individual data formats, content, and time 
stamps, and to verify that the aircraft and ground logs can be correlated. A formal 
debriefing of the flight shall be held with the airborne test operators, ground test 
operators, and the pilots for the purpose of reviewing the test procedures, 
prehminary test results, and to revise as necessary the follow-on flight plans. 


7.3 Test Flight #3. Test Flight #3 shall be the second of four operational data gathering 
flights. The flight parameters for this test flight shall be as follows: 

7.3.1 Flight pattern. Two legs, each leg along a radial from the Atlantic City airport out 
to the lim it of coverage and return, straight and level at 35,000 feet (nominal). 

Flight duration is approximately 2 hours. 

7.3.2 Data Communications. TTM’s shall be transmitted regularly to the WGS at 60- 
second intervals during the first leg of the flight and at 30- second intervals during 
the second leg. The WGS shall cyclically broadcast the full set of standard WTPs 
at 10-second intervals throughout the duration of the test flight. On both legs of the 
flight the airborne operator shall issue requests for WTPs from the request set of 
WTPs. The requests shall be made at 5-minute intervals during the first leg of the 
flight, and at 2-minute intervals during the second leg. The WGS shall broadcast 
the requested WTPs interspersed in among the standard WTPs. 

7.3.3 Post Flight Activities. Upon completion of the test flight, the aircraft and ground 
logs shall be examined to verify the individual data formats, content, and time 
stamps, and to verify that the aircraft and ground logs can be correlated. A formal 
debriefing of the flight shall be held with the airborne test operators, ground test 
operators, and the pilots for the purpose of reviewing the test procedures, 
prehminary test results, and to revise as necessary the follow-on flight plans. 


7.4 Test Flight #4. Test Flight #4 shah be the third of four operational data gathering flights. 

The flight parameters for this test flight shah be as follows: 

7.4.1 Flight pattern. Two (or three) legs, each leg along a radial from the Atlantic City 
airport out to the lim it of coverage and return, straight and level at 24,000 feet 
(nominal). Flight duration is approximately 2 hours. 

7.4.2 Data Communications. TTM’s shah be transmitted regularly to the WGS at 30- 
second intervals. The WGS shah cyclically broadcast the full set of standard 
WTPs at 10-second intervals throughout the duration of the test flight. 
Concurrently, the airborne test operator shall issue requests for request WTPs at 2- 
minute intervals. The WGS shall broadcast the requested WTPs interspersed in 
among the standard WTPs. 
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7.4.3 Post Flight Activities. Upon completion of the test flight, the aircraft and ground 
logs shall be examined to verify the individual data formats, content, and time 
stamps, and to verify that the aircraft and ground logs can be correlated. A formal 
debriefing of the flight shall be held with the airborne test operators, ground test 
operators, and the pilots for the purpose of reviewing the test procedures, 
prehminary test results, and to revise as necessary the follow-on flight plans. 


7.5 Test Flight #5. Test Flight #5 shall be the fourth of four operational data gathering 
flights. The flight parameters for this test flight shall be as follows: 

7.5.1 Flight pattern. Two (or three) legs, each leg along a radial from the Atlantic City 
airport out to the lim it of coverage and return, straight and level at 24,000 feet 
(nominal). Flight duration is approximately 2 hours. 

7.5.2 Data Communications. TTM’s shall be transmitted regularly to the WGS at 15- 
second intervals. The WGS shall cyclically broadcast the full set of standard 
WTPs at 10-second intervals throughout the duration of the test flight. 
Concurrently, the airborne test operator shall issue requests for request WTPs at 1- 
minute intervals. Additionally at one point during the second leg of the flight, the 
airborne operator shall issue a series of requests in rapid succession for each of the 
request WTPs as a channel loading test. The WGS shall broadcast the requested 
WTPs interspersed in among the standard WTPs. 

7.5.3 Post Flight Activities. Upon completion of the test flight, the aircraft and ground 
logs shall be examined to verify the individual data formats, content, and time 
stamps, and to verify that the aircraft and ground logs can be correlated. A formal 
debriefing of the flight shall be held with the airborne test operators, ground test 
operators, and the pilots for the purpose of reviewing the test procedures and the 
prehminary test results. 


8.0 Reference Documents 

8.1 WINCOMM Transport En-Route Scenario Test Requirements, vl.O, dated 10/28/04. 

8.2 ARINC Specification 429P3-18, Mark 33 Digital Information Transfer System (DITS), 
Part 3, File Data Transfer Techniques, October 12, 2001. 

8.3 VDLM3 Operations. Operational procedures for the VDLM3 aircraft and ground 
systems. March 1, 2005. 

8.4 VDL Mode 3 Ground Network Interface (GNI) IP Gateway Interface Control Document, 
FAA-NASA-ICD-01, version 0.5, September 1, 2004. 
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8.5 Software Requirements Specification (SRS) for the CMU-900 Weather Aircraft 
Operational Communications Application (AOC) 

Rockwell Collins document CPN xxx-xxxx-001, issued August 12, 2004. 


9.0 ADPU Test Products 
9.1 Standard Products 


File name 

File size (bytes) 

Description 

prodO_METAR_SPECI.pdu 

4,293 

METAR, SPECI 

prodl_TAF.pdu 

2,977 

Terminal Weather 

prod2_SIGMETS.pdu 

2,544 

SIGMETS, AIRMETS, AWWs 

prod5_PIREPS .pdu 

2,005 

PIREPS 

region0L_prod03 .pdu 

2,220 

Weather Depiction, CONUS 

regionOM_prodO 1 .pdu 

889 

NEXRAD, CONUS 

region0M_prod02 .pdu 

1,527 

NEXRAD w/ Tops, CONUS 

9.2 Request Products 

File name 

File size (bytes) 

Description 

region0L_prod04_fl24_t00.pdu 

2,177 

Winds/Temps, FL24, OOZulu 

region0L_prod04_fl30_t00.pdu 

2,238 

Winds/Temps, FL30, OOZulu 

region0L_prod04_fl34_t00.pdu 

2,311 

Winds/Temps, FL34, OOZulu 

region0L_prod05_fl05_t00.pdu 

923 

Turbulence, FL05, OOZulu 

region0L_prod05_fl24_t00.pdu 

1,074 

Turbulence, FL24, OOZulu 

region0L_prod05_fl30_t00.pdu 

1,256 

Turbulence, FL30, OOZulu 

region0L_prod05_fl34_t00.pdu 

983 

Turbulence, FL34, OOZulu 

region0L_prod06_fl24_t00.pdu 

1,021 

Icing, FL24, OOZulu 

region0L_prod06_fl30_t00.pdu 

723 

Icing, FL30, OOZulu 

regionOU_prodO 1 .pdu 

401 

NexRad, Region: Northwest 

regionOV_prodO 1 .pdu 

508 

NexRad, Region: Northcentral 

regionOW_prodO 1 .pdu 

1,495 

NexRad, Region: Northeast 

regionOY_prodO 1 .pdu 

526 

NexRad, Region: Southcentral 

regionOZ_prodO 1 .pdu 

592 

NexRad, Region: Southeast 
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1.0 Overview 


NASA’s Aviation Safety Program (AvSP) was created for the purpose of making a 
significant reduction in the incidents of weather related aviation accidents by improving 
weather situational awareness. The objectives of that program are being met in part 
through advances in weather sensor technology, and in part through advances in the 
communications technologies that are developed for use in the National Air Space (NAS). 
It is the latter element, i.e. the improvements in aviation communications technologies, that 
is the focus of the Weather Information Communications (WINCOMM) project. 



Figure 1. WINCOMM’s Transport En-route Scenario 


The WINCOMM Project has identified three principal aviation scenarios: (1) general 
aviation, (2) transport en-route, and (3) international / oceanic. Each has its own unique set 
of requirements. The optimal networking solution in each case is different. In the case of 
the Transport En-route Scenario, which is depicted in Figure 1, two near-term aviation 
communications technologies were selected for study. One was the 1090 MHz extended 
squitter (1090ES) technology; the other was the VDL mode 3 (VDLM3) technology. The 
1090ES technology with its ability to broadcast relatively short air-to-air data messages 
was seen as the optimal means of disseminating real time 16-bit long turbulence alert 
messages between airplanes in flight. The VDLM3 technology with its ability to carry 
both voice and data simultaneously was seen as the optimal solution for the air-ground 
links. In particular, VDLM3’s digital data links provide an ideal transport mechanism for 
the uplinking of weather data products while at the same time downlinking turbulence 
sensor data and pilot-initiated requests for specific weather data products. 

Test flights of the 1090ES and VDLM3 data links were conducted to evaluate the 
performance characteristics of the two links under real-world conditions. For the testing of 
the 1090ES air-to-air data links, NASA equipped and flew two research aircraft. The 
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details and results of the 1090ES testing are documented in a companion test report 
(Ref. 1). For the testing of the VDLM3 air- ground data links, a separate series of flight 
tests were conducted. This report deals exclusively with the details and results of the 
VDLM3 testing. 

VDLM3 testing was undertaken by NASA with the cooperation, technical support, and 
facilities of the FAA Wi lli am J. Hughes Technical Center in Atlantic City, NJ, and 
Rockwell Collins personnel from Cedar Rapids, IA. The research aircraft were equipped 
and flown by NASA. Included in the airborne equipment was VDFM3 avionics produced 
by Rockwell Collins. The FAA supplied the ground station. NASA additionally supplied 
the ground-based server that managed the uplink and downlink message traffic. A series 
of five flights were made during the three day period of April 11 - 13, 2005. In the months 
leading up to the flight tests, NASA, the FAA, and Rockwell Collins separately conducted 
extensive laboratory testing at the subsystem level, and then jointly participated in two 
ground tests of the integrated system. 

The VDFM3 flight tests were conducted in accordance with the requirements and 
objectives set forth in the Test Requirements document (Ref. 2) and Test Plan (Ref. 3) for 
the Transport En-route Scenario. In addition, written test procedures were developed and 
followed in the execution of the test flights. 


2.0 VDLM3 Test System 

The major subsystems that comprised the airborne and ground segments of the VDFM3 
test system are depicted in Figure 2. The airborne segment was installed and flown aboard 
NASA’s FearJet 25 research aircraft. It consisted of the VDFM3 avionics, a GPS receiver, 
and the WINCOMM Airborne Computer (WAC). The ground segment, which was located 
at the FAA’s facility in Atlantic City, NJ, consisted of the FAA’s ground station and the 
NASA WINCOMM Ground Server (WGS). 


2.1 The Airborne Segment 

A Rockwell Collins model VHF2100 receiver/transmitter was used as the VDFM3 
radio (VDR). The weather data processing and display functions were handled using a 
Rockwell Collins communication management unit (CMU) together with its companion 
model 900 controller/display (IDC). The IDC also served as the operator interface through 
which requests for specific weather products were issued to the ground station. With the 
exception of the software modifications made to the CMU as identified in Section 4.2 of 
this report, the Rockwell Collins equipment was standard commercially available avionics. 

The airborne computer, i.e. the WAC, handled a number of tasks. The WAC was a 
rack-mounted PC running MS Windows XP. It was equipped with a Condor model CEI- 
520A interface card which provided ARINC 429 (see Ref. 4) compatible serial ports for 
transferring data to the CMU. The computer’s built in RS232 serial ports were used to 


Transport En-Route Scenario 


VDL Mode 3 Test Flight Results 


Page 6 of 36 




receive GPS data from the Honeywell KLN94, and to receive serial data from the monitor 
ports of the CMU and VDR. An LCD screen and keyboard served as the operator 
interface. 



Figure 2. VDLM3 Airborne and Ground Segments 


Of the “429” ports, one was configured for bi-directional communications to transfer 
the turbulence test messages (see Section 3.1) from the WAC to the CMU at operator 
selected intervals of 1 to 99 seconds. A second “429” port was configured to send the 
airplane’s ICAO address to the CMU at fixed 250 milli second intervals. A third “429” 
port was configured to send GPS data to the CMU at one second intervals. 

Of the RS232 ports, one was configured to operate at the 9600 baud rate to receive GPS 
data from the Honeywell KLN94. A second RS232 port also operating at the 9600 baud 
rate was used to receive data from the monitor port of the CMU. A third RS232 port 
operating at 1 15.2 kbaud was used to receive data from the monitor port of the VDR. 

Custom software was developed using Lab VIEW v7.1 to manage and control many of 
the airborne data handling tasks. Among these tasks were: (1) the generation and logging 
of the turbulence test messages, (2) the management of the “429” serial data transfers from 
the WAC to the CMU, (3) the reading and logging of the GPS data from the KLN94, and 
(4) the reformatting of the GPS data for use by the CMU. The Lab VIEW program also 
provided a means to synchronize the system clock of the WAC to the GPS. TeraTerm Pro 
(Ref. 5) was used to log the serial data received from the CMU. Custom software provided 
by Rockwell Collins was used to log the serial data output from the monitor port of the 
VDR. 
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The antenna for the VDR was mounted on the bottom of the fuselage at a mid-ship 
position. The antenna for the GPS receiver was mounted on the top of the fuselage, also at 
a mid-ship position. 

Not shown in Figure 2 is the VDLM3 voice communications link that was used to 
coordinate operations between the airplane and the ground. 


2.2 The Ground Segment 

The FAA ground station served as the VDLM3 ground subnetwork and as the access 
point to the NASA WINCOMM Ground Server (WGS). The ground station consists of 
four primary subsystems: the Multi-Mode Digital Radios (MDRs), the Real Time Platform 
(RTP), the Radio Interface Unit (RIU), and the Ground Network Interface (GNI). 

The MDR consists of the multi-mode digital radio receiver (MDRR) and the multi- 
mode digital radio transmitter (MDRT). The MDRR uses frame markers generated by the 
RIU to determine the slot timing for the downlink bursts. Bursts received within the 
intended time slots are demodulated within the MDRR and sent to the RTP. The outgoing 
voice/data and management bursts from the RTP are sent to the MDRT where they are 
modulated and transmitted using slot timing generated by the RIU. 

The RTP consists of two separate elements: the Octal T1 Framer and the Voice 
Channel Module (VCM). The octal T1 framer sends and receives frames to and from the 
RIU via a high-speed serial link. Frames received from the RIU are transmitted over a 
fractional T1 line to the MDRT at the specified time within the frame. In the reverse 
direction, frames received from the MDRR via the fractional T1 line are time stamped and 
sent to the RIU via the high-speed serial link. The octal T1 framer also supplies system 
timing for use by the VCM and RIU subelements. 

The RTP may contain up to four separate VCMs, providing the voice elements for up to 
four user groups. In the uplink direction, the analog voice input at the headset interface is 
digitized and then compressed by a vocoder. This compressed output is passed to the octal 
Tl, and then sent to the RIU. In the downlink direction, compressed voice frames are 
passed from the RIU on the serial link, decoded in the vocoder and sent to the headset 
interface. 

The RIU subsystem manages the Media Access Control (MAC), Link Management 
Entity (LME), and Data L in k Service (DLS) sub-layers of the VDLM3 subnetwork. The 
MAC layer establishes the time division multiple access (TDMA) timing for the voice, 
data, and management bursts. For these tests the MAC layer was configured in accordance 
with the 2-voice/2-data mode of operation. The LME is responsible for context 
management of each air to ground connection. The DLS determines the data framing for 
both the unicast and broadcast modes of transmission. 
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The GNI serves as the data gateway to the ground station. The data to and from the 
RIU is transferred over an ethernet LAN. Similarly, data to and from the WGS is 
transferred over an ethernet LAN. 

The WGS functions as the data server for the testing. It (1) periodically issued weather 
data products for broadcast to the airplane, (2) issued weather data products for broadcast 
in response to requests generated by operator key presses on the airborne IDC, (3) received 
the turbulence test messages transmitted from the airplane, (4) logged all incoming and 
outgoing message activity, and (5) provided an operator interface for monitoring and 
controlling ground operations. The WGS was implemented on a PC running MS Windows 
XP. Clock synchronization was provided through NTP services supplied via the GNI LAN 
connection. All traffic flowing on the LAN connection between the WGS and the GNI 
was logged using the Ethereal network protocol analyzer software ( Ref 6). 


3.0 Test Messages 

3.1 Turbulence Test Message (TTM) 

The TTMs transmitted during these tests were all 77 bytes in length, consistent with 
the anticipated size of the expanded turbulence data messages. The structure of the TTMs 
is indicated in Table 1. Each TTM bore a timestamp that was derived from the system 
clock in the WAC. The clock was synchronized at the start of the each flight with the GPS 
time. 


Byte No. 

Size 

Content 

Description 

1 - 12 

12 

STURBULENCE, 

Start of message 

13-25 

13 

hh:mm:ss.sss. 

Timestamp 

26-31 

6 

nnnnn, 

Sequence no. 

32-75 

44 

ASCII text string 

Free text message 

76-77 

2 

ASCII c/r and 1/f 

End of message 


Table 1. Turbulence Test Message (TTM) format 


Included within each TTM are a message sequence number and a 44-character free-text 
field. Provisions were made in the WAC software to enable the airborne operator to insert 
short messages into the free-text field and thereby send status information to the ground 
personnel. A typical TTM might therefore appear as follows: 

1 2 3 4 5 6 7 

Byte: 12345678901234567890123456789012345678901234567890123456789012345678901234567 

$ TURBULENCE , 09:19:51.000, 00123, Vf 

$TURBULENCE, 09 : 20 : 51 . 000, 00124, This is a free text message. Vf 

For compatibility with the CMU, the TTMs were first pre-pend with a 5-byte 
accountability header consisting of the 5 hex characters 57h 57h 58h Oh Oh. The resulting 
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82-byte data messages were then formatted in accordance with the Williamsburg version 1 
file transfer protocol as specified in Ref 4. This involved transforming the 82-byte data 
messages into a series of 32-bit words as prescribed by the ARINC 429 data transfer 
protocol. Each 32-bit “429” word carries no more than 5 semi-bytes (i.e. 5 nibbles) of the 
data message. Thus, 33 32-bit “429” words are required to contain one TTM. Two 
additional 32-bit words must be appended to the 33 data words to create the Link Data 
Unit (LDU) used in “429” data transfers. The two additional words are (1) a Start-of- 
Transmission (SOT) word and (2) an End-of-Transmission (EOT) word. Consequently, 
the transfer of the TTMs from the WAC to the CMU was accomplished using LDUs 
containing 35 32-bit “429” words. 


Byte No. 

Size 

Contents 

Description 

1-5 

5 

001 GW 

Header 

6-13 

8 

Ddhhmmss 

Timestamp 

14-20 

7 

Latitude (N1234.5) 

N/S, degs, mins 

21-28 

8 

Longitude (W12345.6) 

E/W, degs, mins 

29-46 

18 

misc. 


47-48 

2 

Sequence ID, ss 

01-99 

49-50 

2 

Region, rr 

0L=continental USA 




0M=USA NEXRAD/T ops/Move 




0U=Northwest US 




0V=Northcentral US 




0W=Northeast US 




0X=Southwest US 




0Y=Southcentral US 




0Z=Southeast US 

51-52 

2 

Product ID, pp 

01=NEXRAD 




02=NEXRAD w/tops 




03=Weather depiction 




04= Winds and Temps 




05=Turbulence 




06=Icing 

53-54 

2 

Fit Level (altitude) (as req'd) 

00=FL000 30=FL300 




05=FL050 34=FL340 




10=FL100 39=FL390 




18=FL180 45=FL450 




24=FL240 53=FL530 

55-56 

2 

Forecast time (as req'd. ) 

00=00Z 36=36HR 




06=06Z 42=42HR 




12=12Z 48=48HR 




18=18Z 60=60HR 




72=72HR 


Table 2. Weather product request message format 
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New TTMs were automatically generated on a timed basis, generally once every 60 
seconds. Additional TTMs, however, were generated on those occasions when the 
airborne operator chose to immediately send a text message to the ground station. The 
LDUs were transferred to the CMU at the 100 kbps data rate using the Williamsburg “Oi” 
full duplex option. The software routines used to generate the TTMs, assemble the LDUs, 
and provide data link flow control were implemented as part of the Lab VIEW program 
installed on WAC. 


3.2 Weather Product Request Messages 

The weather product request messages are generated by the CMU in response to 
operator key presses on the IDC. The request message length was fixed at either 52 or 56 
bytes in accordance with the message structure indicated in Table 2. 


3.3 Weather Test Products (WTPs) 

The weather products used in these tests to evaluate the data handling capabilities of the 
VDLM3 links were conventional text-based and graphical digital data types as listed in 
Table 3. The files were named in a manner consistent with the region and product codes 


Standard WTP Filenames 

Bytes 

Description 

prodO_MET AR_SPECI.pdu 

4,293 

METAR, SPECI 

prodl_TAF.pdu 

2,977 

Terminal weather 

prod2_SIGMETS . pdu 

2,544 

SIGMETS, AIRMETS, AWWs 

region0L_prod03 . pdu 

2,220 

Weather depiction. CONUS 

prod5_PIREPS.pdu 

2,005 

PIREPS 

region0M_prod02 . pdu 

1,527 

NEXRAD w/tops, CONUS 

regionOM_prodO 1 . pdu 

889 

NEXRAD, CONUS 




Request WTP Filenames 

Bytes 

Description 

region0L_prod04_fl24_t00.pdu 

2,177 

Winds/Temps, FL24, 00Z 

region0L_prod04_il30_t00.pdu 

2,238 

Winds/Temps, FL30, 00Z 

region0L_prod04_fl34_t00.pdu 

2,311 

Winds/Temps, FL34, 00Z 

region0L_prod05_fl05_t00.pdu 

923 

Turbulence, FL05, 00Z 

region0L_prod05_fl24_t00.pdu 

1,074 

Turbulence, FL24, 00Z 

region0L_prod05_fl30_t00.pdu 

1,256 

Turbulence, FL30, 00Z 

region0L_prod05_fl34_t00.pdu 

983 

Turbulence, FL34, 00Z 

region0L_prod06_fl24_t00.pdu 

1,021 

Icing, FL24, 00Z 

region0L_prod06_fl30_t00.pdu 

723 

Icing, FL30, 00Z 

regionOU_prodO 1 . pdu 

401 

NEXRAD. Region: Northwest 

regionO V_prod0 1 . pdu 

508 

NEXRAD. Region: Northcentral 

region 0W_prod0 1 . pdu 

1,495 

NEXRAD. Region: Northeast 

regionO Y_prod0 1 . pdu 

526 

NEXRAD. Region: Southcentral 

regionOZ_prodO 1 . pdu 

592 

NEXRAD. Region: Southeast 


Table 3. Weather Test Products (WTPs) 
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listed in Table 2. The graphical products are PNG image files reformatted as ADPUs in 
accordance with RTCA DO-267 (Ref. 7). The textual WTP sizes were chosen based on the 
average product sizes of complete national compressed weather information as observed in 
the Flight Information Services Data Link System (and also in Ref. 8). The textual WTPs 
are uncompressed ASCII files that contain portions of actual national weather products. 

The sizes of the WTPs were scaled down by a factor of seven (7) from the size of the 
corresponding national weather product file size in order to make the WTP file sizes 
consistent with those of regional products. The graphical WTPs are PNG-format files that 
contain actual weather data samples from a weather- intensive day in the U.S. The data in 
the graphical WTPs does not include any geo-political borders, as this information is 
stored and rendered on the IDC. See Appendix B for screen shots of the WTPs. 

For the purposes of these tests, the WTPs were divided into two sets: a standard set and 
a request set. The standard WTPs were broadcast by the ground station on a rotating 
schedule basis. The transmissions were separated by a 10-second inter-message wait 
period. After cycling through all of the products in the standard set, the process was 
repeated starting again with the first product in the set. The request WTPs, on the other 
hand, were broadcast only once in response to a request for that particular WTP. The 
requests were queued by the server upon receipt and subsequently posted to the GNI for 
broadcast. 


4.0 Data Transfer Protocols 

4.1 VDLM3 

The VDLM3 communications took place in full compliance with the protocols and 
procedures established by RTCA MASPS document (Ref. 9) and RTCA MOPS document 
(Ref. 10). The VDLM3 system was configured for operation with two voice channels and 
two data channel, i.e. the so called 2V2D option. Only one of the two data channels was 
used. Voice traffic was occasionally carried on one of the voice channels during the test 
flights. 


4.2 TCP/UDP/IP 

All test messages were transmitted as IP datagrams. TCP/IP v4 was selected as the data 
transfer protocol for the downlinking of (1) the TTM messages and (2) the WTP request 
messages. UDP/IP was selected as the data transfer protocol for the uplink broadcasts of 
the WTPs. The decision to use TCP/IP (versus ATN) was based on the fact that TCP 
provided an entirely adequate reliable data transfer mechanism for the downlinking of the 
turbulence and WTP request test messages from the airplane. In addition, the UDP 
provided a convenient file transfer mechanism for the uplink broadcasts of the WTPs from 
the ground station. The VDLM3 standard allows for the use of IPv4 by setting the IPI 
field in the DLS frame to OxCC as per ISO 9577. It also allows for the use of ATN. 
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However, an ATN implementation would have required the addition of a full ATN 
protocol stack to both the WGS and the CMU. This was seen as an unnecessarily more 
complex and costly alternative. 

IP-based messaging was implemented in the CMU with the addition of the Treck v2.2 
TCP/IP protocol stack to the CMU’s embedded software. IP-based messaging in the 
ground station was implemented using the TCP/IP protocol stack built into the MS 
Windows XP operating system. For the purposes of these tests, no changes were made to 
the Windows XP default TCP timer values in the WGS. The max im um transmission unit 
(MTU) size, however, was changed to 922 bytes for compatibility with the amount of data 
transferred by VDLM3 in one 15-burst data frame (see Figure 3). In the CMU, the key 
TCP/IP stack parameters were set as indicated in Table 4. 


IP Parameters: 

Value 

Support IP fragmentation 

l=Yes 

IP Time to live (TTL) 

64 

IP Type of service (TOS) 

0 

IP fragment re-assembly TTL 

90 seconds 

TCP Parameters: 


Max keep alive count 

8 

Keep alive idle time 

7200 sec. 

Probe timeout interval min. 

500 millisec. 

Probe timeout interval max. 

60 sec. 

Max. retransmit count 

12 

Max. retransmit time 

75 sec. 

Retransmission timeout default 

3 sec. 

Retransmission timeout min. 

2 sec. 

Retransmission timeout max. 

12 sec. 

Delay ACK time 

200 millisec. 


Table 4. Airborne (CMU) TCP/IP parameters 


Message prioritization was implemented using the Type-of-Service (TOS) bits 
contained within the IP headers to convey the VDLM3 priority levels. For the purposes of 
these tests, the standard WTPs were given a high priority by the ground server by having 
their TOS bits set to the value 2. The request WTPs were given a lower priority by the 
ground server by having their TOS bits set to the value 1. The TOS bit settings for the 
TCP flags were unaltered from their default values. Thus, the TCP ACK , SYN, and FIN 
packets were sent with priority 2, while the TCP RST packets were sent with priority 0. 


4.3 VDLM3/IP Effective Data Throughput Rate 

VDLM3, operating in the 2V2D mode, provides a base data transfer rate of 192 
symbols (72 bytes) per 120 milli seconds in each of its two data channels. Excluding the 10 
forward error correction bytes carried in each data burst, the data rate at the data link layer 
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is effectively 62 bytes per 120 milliseconds per data channel. Overhead bytes are added at 
the DLS layer and at the IP layer as indicated in Figure 3. 

At the transport layer, an 8-byte UDP header is pre-pended to the ADPU data block in 
creating a UDP/IP datagram. The UDP datagrams are segmented for transport into a 
number of IP fragments, the size of which is lim ited by the MTU size. With the MTU set 
to 922 bytes, each fragment will contain a max im um of 896 bytes. Hence, an ADPU 
containing N bytes will be segmented into n fragments such that: 


where 

and 

or 


tt — nfull + Hp ar tial 

nfun = Floor [(N + 8) modulo 896] 
impartial = 1 if Remainder [(N + 8) modulo 896] > 0 
n pa rtiai = 0 if Remainder [(N + 8) modulo 896] = 0 


At the link layer, the IP fragments are framed for transport into data link service (DLS) 
frames, each of which adds 8 additional header bytes to each IP fragment. Thus at the 
VDLM3 transport layer, each full DLS frame is transported as a series of 15 VDLM3 
62-byte data bursts plus a proportionately smaller number of bursts for the final IP 
fragment. 


8 N 



1“ Data Burst; 2 nd through 14"’ 15*" Data Burst; 

User Information Data Burst; User User Infonnation 

Information 


1 . Values are based on IP MTU = 922 bytes = (54 + 14*62). 

2. PID = 0x40 and IPI = OxCC indicates an IPvf Datagram. 

Figure 3. Segmentation of VDLM3 / IP data messages 
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Based on the segmentation indicated above, the anticipated delivery time for an ADPU 
varies linearly as a function of its file size as shown in Figure 4. Also shown are the 
number of IP fragments (full and partial) required to deliver the ADPU file. The indicated 
effective transfer rate is nominally 490 bytes per second (3.92 kbps). When compared to 
the 72-byte per 120-millisecond VDLM3 base data rate, i.e. 600 bytes per second, the 
channel efficiency is approximately 82%. In actual practice, the presence of TCP and 
VDLM3 protocol traffic interleaved with the data packets serve to reduce this effective rate 
somewhat. Thus, the 490 byte per second rate per VDLM3 data channel represents the 
maximum effective transfer rate for IP datagrams. 



Figure 4. Maximum anticipated VDLM3 transfer of IP datagrams 


5.0 Flight Profiles 

A series of five test flights of the VDLM3 system were made during the period of 
April 11-13, 2005. All were flown out of the Atlantic City, NJ airport (ACY) within range 
of the FAA’s VDML3 ground station located at the FAA Technical Center. Shown in 
Figure 5 is the flight pattern for Flight #2. The flight patterns for Flights #3 through #5 
(not shown) were similar to that for Flight #2. 

The flights were all made under straight and level conditions, and under generally clear- 
sky conditions. Each flight consisted of four legs: 2 out-bound legs and 2 in-bound legs. 
The turnarounds on the out-bound legs were made approximately 2 minutes after 
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Figure 5. Flight #2 flight path. 


Fhght/Leg 

Altitude 

(feet) 

STD WTPs 
Spacing Datafile 

REQ WTPs 
Interval Datafile 

TTM 

Interval 

2/1 

35,000 

10 sec. 

Full set 

- 

none 

60 sec. 

2/2 

35,000 

10 sec. 

Full set 

5 min. 

Full set 

60 sec. 

2/3 

35,000 

10 sec. 

Full set 

5 min. 

Full set 

60 sec. 

2/4 

35,000 

10 sec. 

Full set 

5 min. 

Full set 

60 sec. 

3/1 

35,000 

10 sec. 

Full set 

5 min. 

Full set 

60 sec. 

3/2 

35,000 

10 sec. 

Full set 

2 min. 

Full set 

30 sec. 

3/3 

35,000 

10 sec. 

Full set 

2 min. 

Full set 

30 sec. 

3/4 

35,000 

10 sec. 

Full set 

2 min. 

Full set 

30 sec. 

4/1 

24,000 

10 sec. 

Full set 

2 min. 

Full set 

30 sec. 

All 

24,000 

10 sec. 

Full set 

2 min. 

Full set 

30 sec. 

4/3 

24,000 

10 sec. 

Full set 

2 min. 

Full set 

30 sec. 

4/4 

24,000 

10 sec. 

Full set 

2 min. 

Full set 

30 sec. 

5/1 

24,000 

10 sec. 

Full set 

1 min. 

Full set 

15 sec. 

5/2 

24,000 

10 sec. 

Full set 

1 min. 

Full set 

15 sec. 

5/3 

24,000 

10 sec. 

Full set 

1 min. 

Full set 

15 sec. 

5/4 

24,000 

10 sec. 

Full set 

1 min. 

Full set 

15 sec. 


Table 5. Fhght parameters 
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observing a complete loss-of-signal. Throughout each flight, the standard WTPs and 
TTMs were transmitted on a regularly scheduled basis. The request WTPs were broadcast 
only in response to a request from the airplane. 

Flight #1 served as a checkout flight. The Flight #1 data is not included in this analysis. 
The data logged during Flights #2 through #5 constitute the test data upon which the test 
results in this report are based. The test flights differ mainly in (1) the altitudes flown, (2) 
the complement of weather products transmitted and requested, (3) the intervals at which 
the operator-initiated WTP requests were issued, and (4) the interval at which the TTMs 
were issued. The flight parameters for each flight are summarized in Table 5. 

Additionally, during the second, third and fourth legs of Flight #5, rapid-fire bursts of 
requests were made for the 14 request WTPs. 

Shown in Figure 6 is a plot of the SQP values obtained during Flight #2. The plot is 
typical of the observed variation in SQP values for all of the flights. The SQP variations in 
the 0-12 minute and 138 - 140 minute timeframes shown in Figure 6 are associated with 
the takeoff and landing maneuvers. The SQP = 0 values that occurred in the 44-minute 
and 104-minute timeframes coincide with the out-of-range turnarounds of the flight. 


Flight #2 



Flight Time (minutes) 

Figure 6. Observed SQP variations - Flight #2 (typical) 
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6.0 Test Results 


6.1 UDP/IP Broadcast Message Results 

As indicated in Table 5, the standard WTPs listed in Table 3 were repeatedly broadcast 
in a cyclical manner. The number of broadcasts made per flights ranged from 407 to 455. 
The total number of WTPs broadcast was 1,705. The success rate was determined by 
matching the IP IDs of the WTPs in the WGS Ethereal logs to those contained in the VDR 
logs and looking for lost WTPs. The dependence of the success rate on SQP was 
essentially the same for all four data flights. Figure 7 was constructed by combining the 
results from the four flights and plotting it as a function of the receive SQP threshold. 



SQP Threshold 

Figure 7. UDP uplink broadcast delivery success rates 


The data acquired during those segments of the flight for which the observed SQP value 
was zero were excluded from the plot. An SQP value of zero indicated that the aircraft 
was effectively out-of-range. 

Shown in Figure 8 are the message delivery times for the seven standard WTPs for 
Flights #2 through #5. The data in these plots was derived from the packet flows captured 
in the VDR logs and the WGS Ethereal logs. Clock corrections were applied to the data as 
explained in Appendix A. The delivery time for a WTP was computed as the difference 
between the timestamp for receipt of the final IP fragment of the WTP from the VDR log 
and the timestamp for the start of the message from the WGS Ethereal log. The observed 
delivery times are consistent with the theoretical maximum transfer rate of 490 bytes per 
second (see Section 4.3). The scatter in the data is believed to be due to the variations in 
the amount of interleaved protocol traffic that existed on the channel during the broadcast. 
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Flight #2 



Figure 8a. Standard WTP delivery times - Flight #2 


Flight #3 



Figure 8b. Standard WTP delivery times - Flight #3 


WTP 

#i 

#2 

#3 

#4 

#5 

#6 

#7 

Bytes 

4,293 

2,977 

2,544 

2,220 

2,005 

1,527 

S89 

Desc. 

METAR 

Term. Wx 

SIGMETS 

Wx CONUS 

PIREPS 

NEXRAD 

NEXRAD 
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Flight Pt - 4 



Figure 8c. Standard WTP delivery times - Flight #4 


Flight #5 



Figure 8d. Standard WTP delivery times - Flight #5 
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6.2 Turbulence Test Message Results 


Shown in Figure 9 are the observed delivery times for the TTMs for the four data 
flights. The data for these plots was obtained from the WGS Ethereal logs. The delivery 
times were computed as the difference between the timestamp for the receipt of the TTM 
and the timestamp written to the time field of the message by the WAC when it was 
created. Clock corrections were applied to the data as explained in Appendix A. 

Considerable variability is observed in the delivery times for all of the flights. Since the 
TTMs were sent periodically throughout the course of each flight, the conditions under 
which the TTMs were transmitted covered a broad range of SQP values: from SQP values 
of 1 1 down to 0. The variations in SQP value do not correlate well with the observed 
scatter in the delivery time data. Instead, it is more likely that the scatter is due solely to 
packet retransmissions. 

Summarized in Table 7 are the TTM results in terms of messages sent versus messages 
received as obtained from the WAC and WGS logs. Significantly, no TTMs were lost, as 
would be expected of a reliable transport protocol. However, through analysis of the 
packet flows in the VDR and WGS Ethereal logs, it was determined that there were 
numerous retransmissions at both the TCP layer and the DLS layer. 



Fit. #2 

Fit. #3 

Fit. #4 

Fit. #5 

TTMs Sent 

136 

122 

217 

444 

TTMs Rec'd. 

136 

122 

217 

444 

TTMs Lost 

0 

0 

0 

0 

Retransmissions: 





at the TCP layer 

5 

6 

20 

34 

at the DLS layer 

55 

32 

49 

93 


Table 6. TCP messaging of the turbulence messages. 


The reason(s) for the inordinately large number of retransmissions that occurred, 
particularly those that occurred at the DLS layer, is not obvious. In some instances there is 
evidence in the packet flows that a con fli ct existed between the TCP and VDLM3 timers. 
However, further study and/or experimentation will be required to isolate the reason(s) for 
the retransmissions and to optimize the protocol timers. In addition, there are other 
potential causes for message latency variations which warrant investigation. These include 
the WAC-to-CMU Williamsburg data transfers and the CMU-to-VDR message processing 
delays. 
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Figure 9a. TTM delivery times - Flight #2 


Flight #3 

13 -r 
12 -- 
11 -- 
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7 -- 
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5 -- 
4 -- 
3 -- 
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0 - 
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Figure 9b. TTM delivery times - Flight #3 
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Figure 9c. TTM delivery times - Flight #4 


Flight #5 



Figure 9d. TTM delivery times - Flight #5 
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6.3 WTP Request Message Results 

Shown in Figure 10 are the observed delivery times for the WTP request messages. 

The data in these plots was derived from the timestamps captured in the VDR log and in 
the WGS Ethereal log. Clock corrections were applied to the data as explained in 
Appendix A. 

As in the case of the TTMs, considerable variability exists in the observed delivery 
times of the request messages. Much of the data is clustered in the 240 milli second 
regime, which corresponds to the transmit time of a 52 or 56 byte message (i.e. two 
120-millisecond VDLM3 data bursts). However, the data in part is also clustered in the 
3-4 second regime, which is suggestive of the 3-second TCP retransmission time of the 
Treck TCP protocol stack. Since the request messages were sent sporadically throughout 
the course of the four data flights, the transmissions occurred under wide ranging 
conditions: under SQP values ranging from 0 to 11. Thus, as in the case of the TTMs, the 
scatter in the data does not correlate well with the SQP value. Instead, it is likely that the 
scatter is due solely to packet retransmissions. Indeed, such is the case as was revealed 
from an analysis of the packet flows obtained from the VDR and WGS Ethereal logs. 

Summarized in Table 7 is the number of request messages sent versus the number 
received. This data was obtained from the VDR log and from the WGS Request log. The 
fact that not one of the request messages was lost is to be expected given that the messages 
were sent using a reliable transport protocol. However, an analysis of the packet flows 
indicates that a substantial number of retransmissions had taken place, especially at the 
DLS layer. The reason for these retransmissions is not immediately obvious. The packet 
flows, though, suggest that they may be due to inappropriately set TCP timers relative to 
the VDLM3 timers. Further study and experimentation will be required to optimize the 
system parameters. 



Fit. #2 

Fit. #3 

Fit. #4 

Fit. #5 

REQs Sent 

16 

43 

43 

102 

REQs Rec'd. 

16 

43 

43 

102 

REQs Lost 

0 

0 

0 

0 

Retransmissions: 





at TCP layer 

5 

11 

6 

6 

at DLS layer 

4 

20 

8 

30 


Table 7. TCP messaging of the WTP request messages. 

It should be noted that there was a difference at the application protocol layer of the 
ground server for TCP connections of the request messages and the TTMs. In the case of 
the request messages, the ground server was programmed to drop the current connection 
after 2.5 minutes of inactivity and establish a new connection upon receipt of the next 
request message. In the case of the TTMs, the ground server was programmed to maintain 
the connection indefinitely. No evidence, however, was found to suggest that this 
difference contributed materially to the scatter in the delivery times of the request 
messages. 
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Delivery Time (seconds) Deliver Time (seconds) 


Flight #2 



Flight Time (minutes) 

Figure 10a. WTP Request message delivery times - Flight #2 


Flight #3 



Flight Time (minutes) 

Figure 10b. WTP Request message delivery times - Flight #3 
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Figure 10c. WTP Request message delivery times - Flight #4 


Flight #5 
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Figure lOd. WTP Request message delivery times - Flight #5 
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7.0 Concluding Remarks 


These tests establish VDLM3 as a viable medium for the delivery of weather data to 
airplanes in flight. Furthermore the tests demonstrate that VDLM3 can be combined with 
a reliable transport protocol such as TCP/IP for point-to-point air-to-ground messaging. 
And importantly, the tests demonstrate that VDLM3 can be combined with a best-efforts 
transport protocol such as UDP/IP for ground-to-air broadcasts of aviation weather data 
products. 

Packet retransmissions resulting from inappropriately set protocol timers were found to 
introduce large variations in the delivery times of the data messages, thus degrading the 
average delivery times of the data messages. Further study and/or experimentation will be 
required to optimize the protocol timers and thereby achieve optimally responsive 
applications. 
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APPENDIX A - Clock Corrections 


The time stamps for the various data sets recorded as part of this study were derived 
from four different clocks: (1) the WAC system clock, (2) the CMU internal clock, (3) the 
VDR internal clock, and (4) the WAC clock. At the start of each flight the WAC clock 
was synchronized to the airborne GPS time. The WAC in turn passed its clock timing to 
the CMU (via an ARINC 429 serial port). The VDR subsequently synchronized its clock 
to the CMU clock. At the ground station the WGS was synchronized to an NTP server via 
the ethernet link to the GNI. In reviewing the various data sets, it became apparent that the 
synchronization process did not achieve a perfectly synchronized set of clocks. Not only 
were there significant offsets found among these four clocks, but also a significant drift. 

The difference between the VDR and WGS clocks was obtained by noting the 
differences between the timestamps in the packet flows for the TCP ACKs when they were 
received at the VDR versus when they were transmitted from the WGS. The ACKs were 
selected because of their small fixed (52 byte) packet size, thus assuring that the two 
timestamps should be 120-millisecond apart, i.e. the time of one VDLM3 data burst. In 
order to compare the timestamps, the VDR logs were first converted to the Libpcap format. 
This made it possible to compare the VDR packet flows with those captured by Ethereal at 
the WGS. Plots of the timestamp differences, minus the 120 milli second delivery time, are 
shown on the following pages. The plots indicate that the VDR clock drifted linearly with 
respect to the WGS clock. 

In a similar manner, the difference between the VDR and WAC clocks was obtained by 
noting the differences between the timestamps in the packet flows for the arrival of the 
TTMs at the VDR versus the timestamps embedded in the TTM itself by the WAC. Plots 
of these timestamp differences are also shown on the following pages. The plots indicate 
that the VDR and WAC clocks were offset by a fixed amount with no apparent drift. 

The data plotted in Figures 8 and 10 were corrected by applying the linear clock 
correction for the VDR-WGS synchronization error. The data plotted in Figure 9 were 
corrected by applying both the VDR-WGS linear clock correction and the constant offset 
VDR-WAC clock correction. 
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VDR-WGS Clock Corrections (continued) 



R-WAC Clock Corrections 



Flight Time (minutes) 


Transport En-Route Scenario 


VDL Mode 3 Test Flight Results 


Page 30 of 36 



Clock Diff. (seconds) Clock Diff. (seconds) Clock Diff. (seconds) 


VDR-WAC Clock Corrections (continued) 
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APPENDIX B - Weather Test Products 


On the following pages are screen photographs of the standard and request WTPs as 
they appeared on the IDC. The graphical images were in color. The data files do not 
contain the geo-political boundaries; the boundaries were added by the IDC. 
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Standard WTPs 


2/2- 


DLNK -METAR/SPECI 
METAR KCLE 151 751 Z 
21013KT 10SM FEW 150 
SCT200 BKN250 14/06 
A2996 

RMK A02 SLP147 
8/075 T01440061 10144 
20044 58025 

METAR KLPR 151753Z AUTO 
23016G21KT 10SM CLR 


VOICE MODE 
< RETURN 18:49 



DLNK -PIREPS 1 /13 

LPR UUA /OV MFD020025/TM 
1733/FL060/TP CYMP/TB 
SEV 030-045/RM DURGC 


HLC UA /OV HLC/TM 
1815/FL100/TP C10/TA 
M4/IC LGT RIME/RM FM ZDV 


GCN UA /OV GCN/TM 


VOICE MODE 
< RETURN 18:50 


METAR, SPECI (4,293 bytes) 


PIREPS (2,005 bytes) 


DLNK -TERM WX 1/,- 

TAF KCLE 151727Z 151818 
2201 2KT P6SM BKN120 
OVC250 

FM2300 20006KT P6SM 
OVC100 TEMPO 0405 5SM 
-RA BR OVC050 

FM0500 32008KT 4SM 
-RA BR OVC025 TEMPO 0708 
2SM -RASN BR 


VOICE MODE 
< RETURN 18:49 


Terminal Weather (2,977 bytes) 



NEXRAD, w/tops (1,527 bytes) 


DLNK -SIGMETS 4/17 

AIRMET IFR...WI IL LM IN 
MI 

FROM 20E MBS TO 10SSE 
DXO TO FWA TO 10SSE BDF 
TO 30ESE DBQ TO 
10SSE BAE TO 20E MBS 
OCNL CIG BLW 010/VIS BLW 
3SM PCPN/BR/FG. CONDS 
ENDG WI IL LM IN 

VOICE MODE 
< RETURN 18:49 


SIGMETS, AIRMETS (2,544 bytes) 



NEXRAD, CONUS (889 bytes) 



Weather Depiction (2,220 bytes) 
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Request WTPs 




Winds/Temps, FL24, OOZ (2,177 bytes) Turbulence, FL24, 00Z (1,074 bytes) 




Winds/Temps, FL30, OOZ (2,238 bytes) 


Turbulence, FL30, OOZ (1,256 bytes) 



Winds/Temps, FL34, OOZ (2,311 bytes) 


Turbulence, FL34, OOZ (983 bytes) 




Turbulence, FL05, OOZ (923 bytes) 



Icing, FL24, OOZ (1,021 bytes) 
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Request WTPs (continued) 





NX 


V2819142 


1 

~ 1 ^^1 

9/17 

Cc' 

1 h 

1 ) \ 


□ 

Itl 



Icing, FL 30, 00Z (723 bytes) 


NEXRAD, Northwest (401 bytes) 


NEXRAD, Northcentral (508 bytes) 


NEXRAD, Northeast (1,495 bytes) 


NEXRAD, Southcentral (526 bytes) 


NEXRAD, Southeast (592 bytes) 
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1.0 SCOPE 

One of the goals of the Weather Information Communications 
(WIN COMM) project is to develop advanced communications and 
information technologies to enable reliable and timely dissemination of 
weather information to aircraft. 


No single data link was considered optimal for the distribution of weather 
data for air to air, ground to air broadcast, and air to ground two-way 
communication. Therefore, it was necessary for WINCOMM to 
implement a hybrid approach. VDLM3 was selected for own ship 
turbulence events to ground users and 1090ES was chosen to transmit 
own ship turbulence data to other aircraft. The choice for 1090ES was 
facilitated by the announcement by the FAA that 1090ES shall be the data 
link for commercial operators for Automatic Dependent Surveillance 
Broadcast (ADS-B). 


To research this approach, WINCOMM initiated a Flight Testing program 
to evaluate these communications links in an actual flight environment. 
1090 Extended Squitter (1090ES) is the data link of focus in this paper. 
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2.0 INTRODUCTION 

1090 Extended Squitter, which is based on Mode S technology, is an 
extended use of the standard 1090MHz transponder frequency. The 
standard 1090ES use is the transmission of position information off of the 
aircraft utilizing Automatic Dependent Surveillance Broadcast (ADS-B) 
transmissions. 


WINCOMM used an ADS-B transmission to transmit Turbulence Test 
Alert (TTA) messages to other aircraft. Since a normal ADS-B contains 
positional information as well as the time and altitude, there is no need for 
this data to be duplicated in the turbulence message. As a result, all 16 
bits of the TTA can be used for weather related data. These additional 16 
bits will be inserted as a payload to a standard ADS-B message, in 
compliance with DO-260A [RTCA2003], 


Ultimately, an algorithm that is fed input from various sensors onboard 
the aircraft would determine the normalized turbulence information. The 
normalized turbulence information output from the algorithm would be 
used to generate a TTA message. However, during these flight tests, 
emulated turbulence information was exchanged due to the absence of 
such an algorithm. 
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3.0 GOALS and OBJECTIVES 

The goal of the 1090ES test is to successfully demonstrate the transmission 
of weather data over the 1090 communication link. More specifically, the 
weather data represents a turbulence test alert message. 


ICAO Annex 10, Volume II, Amendment 77 defines the BDS (Comm-B 
Data Selector) code 4, 5 as the Meteorological Hazard Report [WIL2004]. 
Its purpose is to supply reports on the severity of meteorological hazards 
BDS 4, 5 are the registers where the turbulence test alert message is to be 
stored. However, the contents of these registers have been re-defined as 
outlined in Appendix A. 


Again, the main goal of this flight campaign was to determine if 1090ES is 
a viable data link for the transmission of turbulence test alert messages. 
This goal can be satisfied by accomplishing the four objectives defined 
below: 


1) Modification of COTS non-diversity transponder to accommodate 
turbulence data from a sensor and send it in a 1090 Extended 
Squitter, 

2) Assurance that COTS software provided with the 1090 hardware 
would recognize the squitter data type associated with the 
turbulence test alert message, 

3) Development of custom code to send emulated turbulence sensor 
messages, 

4) Execution of several flight tests to verify proper operation in a 
characteristic environment. 
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4.0 1090ES TEST SYSTEM 

The 1090ES Test System involved the use of two aircraft. Each aircraft 
was equipped with a Commercial Transport 1090ES Flight Rack. Each 
rack contained a Honeywell KT73 panel mount transponder capable of 
providing 1090MHz Extended Squitters, a Honeywell KLN94 Global 
Positioning System (GPS) unit, a WINCOMM Airborne Computer, and a 
Sensis 1090 Remote Unit (RU). The Sensis RU monitored the incoming 
turbulence messages and the Honeywell KT73 transmitted the outgoing 
turbulence messages. Figure 4.0-1 shows the flight rack with their 
respective connections. 


GPS 

(Honeywell 

KLN94) 


RS232 


WINCOMM 
AIRBORNE 
COMPUTER - 


Incoming 
Turb. Alert 


RS232 


Upper Ant. 

1090ES Rx~j Y 


Ethernet (Sensis RU) 1090 MHz 


Outgoing 
Turb. Alert 
ARINC 429 


tower Ant. 


1090ES Tx 
(Honeywell 
KT 73) 


1090 MHz 


Figure 4.0-1 Commercial Transport 1090ES Flight Rack 


The data flow of the 1090ES is also exhibited in figure 4.0-1. Periodically, 
the Wincomm Airborne Computer would generate a Turbulence Test 
Alert (TTA) message. This TTA is sent via an ARINC 429 bus to the 
Honeywell KT73 for transmission. The KT73 encapsulates the TTA as part 
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of a larger ADS-B message and transmits it. Any 1090ES equipped aircraft 
would be able to receive the message. 


Remember that as a part of this test, there is another nearby aircraft 
transmitting similar information in the same manner. Again, using figure 
4.0-1, this incoming turbulence alert would be received by the Sensis 
Remote Unit (RU) and forwarded onto the Wincomm Airborne Computer 
for processing and logging. 


The Honeywell KLN94 is used to accurately record the current position of 
the aircraft. This information is logged for correlation with the 1090ES 
data as part of the post processing. The KLN94 also feeds GPS data into 
the KT73 for the standard ADS-B messages. 
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4.1 HARDWARE 

4.1.1 Honeywell KT73 

The KT73 is a Commercial Off the Shelf (COTS) transponder 
that has been slightly modified to accept turbulence 
(weather) data from a turbulence sensor. The turbulence 
sensor was emulated on the Wincomm Airborne Computer. 
The turbulence data that was received from the turbulence 
sensor is used to generate a 1090 Extended Squitter. It is 
ultimately transmitted out of the KT73. 

4.1.2 Honeywell KLN94 

The KLN94 is a Commercial Off the Shelf (COTS) panel 
mountable color Global Positioning System (GPS) with 
moving map display. 

4.1.3 WINCOMM Airborne Computer 

The WINCOMM Airborne Computer (WAC) is an Intel- 
based rack mount computer running Windows XP. It runs 
all of the software defined in section 4.2. 

4.1.4 Sensis 1090 Remote Unit 

The Sensis 1090 Remote Unit (RU) receives the Mode S 
addressed and Mode S broadcast messages as well as the 
1090 Extended Squitters. The RUs also decode, and time 
stamp ADS-B long squitters. Mode S short squitters, and 
other Mode S (1090ES turbulence messages) from all targets. 


Commercial Transport Scenario 1090ES Test Report 




WINCOMM Project - Commercial Transport Scenario 

1090 Extended Squitter Test Report 

Document No.: CTS-1090-1 

Revision: 1.0 

Date: September 16, 2005 

Page 12 of 39 


4.2 SOFTWARE 

4.2.1 Turbulence Sensor 

In lieu of an actual sensors and a turbulence algorithm, 
custom software was written in Lab VIEW to generate 
turbulence messages. These turbulence messages are also 
known as Turbulence Test Alert (TTA) messages. 


The turbulence test alert messages utilized sixteen (16) bits 
in the 1090ES message. They were formatted as a payload to 
a standard ADS-B message, in full compliance with DO- 
260A. The relatively small size of the TTA can be attributed 
to the fact that a standard ADS-B message already contains 
the parameters time, latitude, longitude, and altitude. For 
the purposes of this test, these 16 bits represented a 16-bit 
integer that was incremented with each transmission. 


A unique ARINC 429 label was assigned to the turbulence 
data. At a user selectable rate not to exceed every five 
seconds, a turbulence message was generated and sent to the 
KT73. Upon successful transmission of the message by the 
KT73, the TTA message is echoed back to the WAC on a 
high speed ARINC 429 interface. 


The format of the actual turbulence message is outlined in 
Appendix A, Extended Squitter Format. 


4.2.2 GPS Logger 

Custom software was developed in Lab VIEW to read GPS 
data from the KLN94. This data was saved and written to 
disk in one second intervals. 
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4.2.3 Portable Display Terminal 

The Portable Display Terminal (PDT) is software developed 
by the Sensis Corporation for use in control and monitoring 
of the 1090 Remote Unit (RU). By applying appropriate 
filters, the data type of the Turbulence Extended Squitter can 
be displayed and saved. 
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4.3 INTERFACES 

4.3.1 KLN94 and GPS Logger 

The link between the KLN94 and the GPS Logger was an RS- 
232 port operating at 9600 baud. 

4.3.2 KT73 and Turbulence Emulator 

The link between the KT73 and the turbulence emulator was 
ARINC 429. The turbulence data was sent to the KT73 over 
a low speed ARINC 429 interface. To assure that the 
turbulence data was received and squittered, an echo was 
returned on a high speed ARINC 429 link. 

4.3.3 PDT and 1090 Remote Unit 

The link between the Portable Display Terminal (PDT) and 
the 1090 Remote Unit was Ethernet running at 10Mbps. 

4.3.4 KLN94 and KT73 

The link between the KLN94 and the KT73 was an RS-232 
port operating at 9600 baud. 
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5.0 TEST FLIGHTS 

5.1 AIRCRAFT 

The aircraft used during the test flights were the NASA Glenn 
Learjet 23 and Learjet 25. 

5.2 LOCATION 

All of the flights for 1090ES were flown out of Cleveland Hopkins 
Airport in Cleveland, Ohio. 

5.3 TIMES 

There were four test flights flown for 1090ES. They were on May 
17, May 19 (2), and June 15. 

5.4 PATHS 

The flight paths are depicted in figures 5.4-1 through 5.4-4. On all 
of the days except June 15, the most westerly flights are the Learjet 
23. On June 15, the Learjet 23 is the easternmost flight. 

5.5 TURBULENCE TEST ALERT (TTA) FREQUENCY 

The frequency of the TTAs was altered throughout the test flights 
to provide various loading conditions for the communications link. 


On the first test flight. May 17, the TTAs were sent out once every 
minute. On May 19, the TTAs were transmitted at thirty (30) 
second and at twenty (20) second intervals for the first and second 
flights of the day, respectively. On June 15, the interval between 
transmissions was also set at twenty (20) seconds. 
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May 17, 2005 
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Figure 5.4-1 


Commercial Transport Scenario 1090ES Test Report 


WINCOMM Project - Commercial Transport Scenario 

1090 Extended Squitter Test Report 

Document No.: CTS-1090-1 

Revision: 1.0 

Date: September 16, 2005 

Page 17 of 39 


May 19, 2005 - First Flight 
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May 19, 2005 - Second Flight 
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June 15, 2005 
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Figure 5.4-4 
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5.6 SEPARATION DISTANCES 

The separation distance between the N616NA and N933NA during 
their flights is depicted in Figures 5.5-1 through 5.5-4. The test 
requirements estimated a separation distance of 75 nautical miles 
(nm) based upon power levels, antenna, cable loss, etc. Since the 
exact range was not known, the separation distance on the first 
flight was rather large. 

On subsequent flights, a concentrated effort was made to minimize 
the separation distances. The researchers onboard the aircraft 
monitored the reception of data from the other aircraft. Once a 
total loss of data reception was experienced, the flight crew was 
notified. Working with Air Traffic Control (ATC), the flight crew 
then attempted to bring the planes closed together to restore the 
signal. 
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N616NA and N933NASeparation Distance (nm) 
May 19, 2005 - First Flight 
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6.0 TEST RESULTS 

6.1 Raw 1090ES Data 

Table 6.1-1 outlines the number of 1090 Extended Squitters sent and 
received on the various flight dates. The direction is the path of the 
data (i.e. 616 to 933, would be data sent from the Learjet 25 
N616NA and received on the Learjet N933NA). It should be noted 
that this table includes all 1090ES messages sent, including those 
sent while the two airplanes set side by side on the tarmac. In 
section 7.0 and the respective tables, messages sent and received 
when the two aircraft were less than three (3) nautical miles were 
filtered out. 


Date 

Direction 

Sent 

Received 

% Received 

May 17 

616 to 933 

42 

20 

47.6% 

May 17 

933 to 616 

28 

17 

60.7% 

May 19-1 

616 to 933 

98 

26 

26.5% 

May 19-1 

933 to 616 

130 

40 

30.8% 

May 19-2 

616 to 933 

240 

70 

29.2% 

May 19-2 

933 to 616 

253 

76 

30.0% 

June 15 

616 to 933 

87 

27 

31.0% 

June 15 

933 to 616 

230 

47 

20.4% 

TOTAL 


1108 

323 

29.2% (average) 


Table 6.1-1 1090 Extended Squitters Sent and Received 
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6.2 Distribution of 1090ES Messages received versus Confidence 
Level 

1090 Extended Squitters that are received at the Remote Unit (RU) 
are decoded and monitored by the Portable Display Terminal 
(PDT). The PDT software will display the Confidence Level of each 
squiffer. Possible values and the respective meaning of the 
Confidence Level are depicted in table 6.2-1. 


CONFIDENCE 

MEANING 

LEVEL 


0 

Too many errors to correct 

1 

Reply error detected and not corrected 

2 

Reply error detected and corrected 

3 

Reply decoded with no corruption detected 


Table 6.2-1 Confidence Levels 


All four of the confidence levels were seen during the 1090ES flight 
tests. Table 6.2-2 represents the distribution of the Confidence 
Levels (CL) for each of the flights. 
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Date 

Direction 

Received 

CL3 

CL2 

CL1 

CL0 

May 17 

616 to 933 

20 

20 

0 

0 

0 

May 17 

933 to 616 

17 

17 

0 

0 

0 

May 19-1 

616 to 933 

26 

22 

3 

0 

1 

May 19-1 

933 to 616 

40 

36 

1 

3 

0 

May 19-2 

616 to 933 

70 

64 

4 

2 

0 

May 19-2 

933 to 616 

76 

67 

5 

1 

3 

June 15 

616 to 933 

27 

26 

0 

1 

0 

June 15 

933 to 616 

47 

36 

4 

7 

0 

TOTAL 


323 

288 

17 

14 

4 

% of 
TOTAL 



89.2 

5.3 

4.3 

1.2 


Table 6.2-2 Confidence Level Distribution 


6.3 Distribution of 1090ES Messages received versus Separation 
Distance between the Aircraft 

The test flights were conducted under level flight conditions with 
each aircraft at relatively the same altitude. The initial 
requirements were to keep the separation distance around 75 
nautical miles. However, a decision made at flight time was to fly 
until coverage was lost. On subsequent flights, every attempt was 
made to minimize the separation distance. It should be noted that 
the Cleveland Hopkins airport is not far from the Cleveland Air 
Route Traffic Control Center (ARTCC), one of the busiest such 
facilities in the world. Therefore, the most desirable routes were 
not always readily available, especially on a short notice. 


As expected, the number of 1090ES received dropped off as a 
function of distance. However, on May 17, a notable number of 
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valid Turbulence Test Alert messages were received at distances 
greater than 150nm. These distances greatly exceed the 90nm for 
low density environments stated in the ADS-B MASPS. 


It is beyond the scope of this document to formulate a justification 
for this. In addition, no roll, pitch, or yaw data was accumulated 
during these flights. However, it is surmised that the orientation of 
the antennas had an affect on the performance of the link on this 
particular day. 


On June 15, it is apparent that N616NA suffered a software or 
hardware failure. As can be seen from Figure 6.3-1, the only data 
that is available is while the two aircraft are still parked at the 
hangar (the separation distance never increases). Reviewing the 
GPS data that was logged for both the N616NA and N933NA 
reinforces this premise. The GPS data gathered on the N616NA 
ended over forty (40) minutes before the data logging stopped on 
the N933NA. 
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FIGURE 6.3-1 Turbulence Message Number versus Separation Distance 

616 to 933 
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FIGURE 6.3-2 Turbulence Message Number versus Separation Distance 

933 to 616 
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7.0 CONCLUDING REMARKS 

As outlined in section 3.0, there were four (4) objectives established for the 
Commercial Transport Scenario 1090 Extended Squitter Tests. The first 
objective was to show that a COTS transponder with only a minor 
modification can receive data from a turbulence sensor and send this data 
over a 1090 link. This objective was met by a contract to Honeywell to 
modify a KT73. 


The second objective was to ensure existing 1090 monitoring software 
provided with the 1090 equipment would recognize the message type of 
the Turbulence Extended Squitter. This was accomplished via laboratory 
testing with the Portable Data Terminal and the respective software. This 
was completed. 


As stated earlier, a deployed system would utilize a turbulence algorithm 
that receives input from various sensors onboard the aircraft to generate a 
turbulence alert message. However, it was beyond the scope of this effort 
to develop such an algorithm. In addition, when it was realized that the 
aircraft would have to fly through turbulence to generate a message and 
the number of messages actually generated may be small, a turbulence 
sensor emulator idea surfaced. This was accomplished by developing 
custom code and thus satisfied the third objective. 


The final objective was to demonstrate the technology in a characteristic 
environment. This was accomplished by the four flights campaigns. The 
performance characteristics of the Learjet's are very similar to those of a 
commercial transport aircraft, in speed and altitude ability. In addition, 
the air traffic density of the Cleveland Sector presents essentially a worst 
case scenario. The Cleveland Sector was the densest at the time of this 
writing. Thus, the flights were very representative of an environment in 
which 1090 would expect to experience. 
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Overall, the tests exhibited that 1090 is a capable means of broadcasting 
aviation turbulence data between aircraft. As can be seen from the tables 
7.0-1 and 7.0-2, when the received data is filtered to a separation distance 
between 3 and 100 nautical miles (lOOnm has been identified as the range 
of a terminal area squitter station [RTCA2003]), the number of messages 
received is nearly 25%. Three nautical miles was chosen as the lower limit 
as this is the minimum distance specified for the separation of aircraft 
operating within 40 miles of a radar antenna site [FAA2004]. The lower 
limit of three nautical miles has the benefit of eliminating the messages 
sent and received while the two planes were sitting side by side on the 
tarmac. As would be expected, these messages had a very high success 
rate. 
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Date 

Direction 

Largest 

Separation 

Distance 

Recorded 

(nm) 

Separation 

Distance 

(nm) 

Sent 

Received 

% of sent 
messages 
received 

May 17 

616 to 933 

256.4 

3<sd<100 

9 

6 

66.7 



>100 

29 

10 

34.5 

May 17 

933 to 616 

3<sd<100 

11 

5 

45.5 



>100 

10 

5 

50.0 

May 19 - 1 

616 to 933 

184.8 

3<sd<100 

54 

15 

27.8 



>100 

34 

2 

5.9 

May 19 -1 

933 to 616 

3<sd<100 

53 

16 

30.2 



>100 

34 

0 

0.0 

May 19 - 2 

616 to 933 

160.8 

3<sd<100 

98 

27 

27.6 



>100 

90 

1 

1.1 

May 19-2 

933 to 616 

3<sd<100 

105 

28 

26.7 



>100 

88 

0 

0.0 

June 15 

616 to 933 

66.6 

3<sd<100 

0 

0 

0.0 



>100 

n/a 

n/a 

n/a 

June 15 

933 to 616 

3<sd<100 

171 

26 

15.2 



>100 

n/a 

n/a 

n/a 


Table 7.0-1 1090ES Sent and Received as a function of Separation Distance (nm) 
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Direction 

Largest 

Separation 

Distance 

Recorded 

(nm) 

Separation 

Distance 

(nm) 

Sent 

Received 

% of 
total 
received 

TOTALS 

616 to 933 

256.4 

3<sd<100 

161 

48 

29.8 




>100 

153 

13 

8.5 


933 to 616 


3<sd<100 

340 

75 

22.1 




>100 

132 

5 

3.8 


COMBINED 


3<sd<100 

501 

123 

24.6 




>100 

285 

18 

6.3 


Table 7.0-2 1090ES Sent and Received as a function of Separation Distance (nm) 

(compilation) 
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ACRONYMS 


ADS-B 

Automatic Dependent Surveillance - Broadcast 

ARTCC 

Air Route Traffic Control Center 

ATC 

Air Traffic Control 

CL 

Confidence Level (as it refers to a 1090ES) 

COTS 

Commercial Off the Shelf 

ES 

Extended Squitter 

FAA 

Federal Aviation Administration 

GPS 

Global Positioning System 

PDT 

Portable Display Terminal 

RU 

Remote Unit 

TTA 

Turbulence Test Alert message 

VDLM3 

VHF Data Link Mode 3 

WAC 

Wincomm Airborne Computer 

WINCOMM 

Weather Information Communications 

1090ES 

1090MHz Extended Squitter 
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APPENDIX A 

EXTENDED SQUITTER FORMAT 


DATA TYPE CODE = 23 (TEST) 


SUBTYPE CODE = 6 


Turbulence Message Byte 1 


Turbulence Message Byte 2 


Padded with Zeros 
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APPENDIX B: Ancillary Data 


time vs. separation distance (nm) 
May 17, 2005 



cJcntDCOOCOLDOJO) 
■^■^( Mco ^ t -^ t-Lnoo 
CDCDCOCDCDCOCDI^I — 


♦ 6 1 6to933 —"—93310616 


time vs. separation distance (nm) 
May 19, 2005 First Flight 


120.00 

100.00 

80.00 

60.00 

40.00 

20.00 
0.00 


♦ 


♦ 

♦ 



CD 

CD 

o 

CM 


CD 

CO 

o 

CM 


CD 

CO 

'yt; 

o 

y 

CM 

CO 

yt; 

o 

y 

CM 

CO 



c\i 

0~) 

CD 

CO 

o 

CO 

LO 

CM 

CD 

LO 

O 

y 

y 

CM 

CO 

yt; 

yt; 

LO 

O 

O 

cSJ 

CO 

CO 

CO 

CO 

CO 

CO 

CO 

CO 



T~” 





T - 







♦ 61 6to933 ■ 933to61 6 


Commercial Transport Scenario 1090ES Test Report 


WINCOMM Project - Commercial Transport Scenario 

1090 Extended Squitter Test Report 

Document No.: CTS-1090-1 

Revision: 1.0 

Date: September 16, 2005 

Page 38 of 39 


APPENDIX B (cont.): Ancillary Data 
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